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1 .  Introduction 

1.1  purpose 

fne  Automated  Interactive  Simulation  Model  (AISIM)  System  pro¬ 
vides  tne  user  witn  tne  ability  to  do  nigh  level  simulation  of 
complex  operational  and  distriouted  data  processing  systems.  Tne 
purpose  of  tnis  manual  is  to  provide  tne  AISIM  user  witn  a  sec  of 
examples  wnicn  demonstrate  tne  use  of  AISIM  on  proDiems  silica  are 
typical  of  its  application  area.  An  AISIM  methodology  is 
presented  and  applied  to  each  problem.  Each  example  in  tnis 
document  is  presented  in  sucn  a  way  as  to  provide  a  standard  for 
documenting  an  analysis  effort  using  AISIM. 

file  emphasis  of  tnis  manual  is  on  now  to  translate  a  problem 
statement  into  a  simulation  model.  For  tnis  reason,  tne  focus  of 
tnis  manual  is  on  model  design  and  construction.  Little  atten¬ 
tion  is  paid  to  tne  results  of  tne  simulation  exercises.  This 
approacn  is  somewhat  different  from  tne  one  tne  user  will  taxe 
wiien  developing  aISIM  models  for  analysis  of  systems  because  tnen 
tne  results  will  be  of  significant  importance.  ft - 

1.2  Scope 

This  manual  describes  tne  use  of  the  AISIM  applied  to  specific 
problems.  Tne  proolems  in  this  document  have  been  selected  based 
on  the  anticipated  use  of  AISIM  for  the  analysis  of  command,  con¬ 
trol  and  communication  systems  in  the  conceptual  pnase  of 
development.  fne  problems  are  presented  in  context  to  an  emerg¬ 
ing  methodology  based  on  AISIM  simulation.  Although  tne  problems 
are  specific  to  embedded  computer  communication  systems,  tne 
metnodology  nas  a  wider  scope.  AISIM  can  be  used  to  analyse  tne 
dynamics  of  many  types  of  systems.  The  techniques  and  strategies 
discussed  in  this  document  would  be  beneficial  to  anyone 
interested  in  discrete  event  simulation  analysis. 

fne  reader  is  expected  to  be  a  system's  analyst  wno  has  experi¬ 
ence  analyzing  conceptual  designs  of  a  mul ti-processing ,  computer 
based  system.  Tnis  document  does  not  contain  information  neces¬ 
sary  to  operate  AISIM  nor  does  it  address  the  hardware  and 
software  environments  for  AISIM.  It  is  anticipated  tnac  tnis 
document  will  be  read  oy  a  user  after  reading  the  AISIM  Training 
Manual . 


1 . 3  organization 

This  manual  is  organized  to  be  a  teaching  document  for  tne  AI3IM 
user.  Chapter  1  introduces  tnis  document,  detailing  tne  organi¬ 
zation,  tne  document  conventions  and  applicable  documents. 
Chapter  2  is  an  discussion  of  the  AISIM  methodology.  Chapter  3 
contains  a  detailed  example  of  tne  use  of  AISIM  to  model  a  com¬ 
munications  network.  Chapter  4  contains  a  description  of  AISIM 
applied  to  another  communication  network  using  a  loop 
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communication  protocol.  Caapter  5  contains  an  example  of  a  com¬ 
munication  system  usin^  a  Das. 

1 . 4  documentation  Contentions 

Tae  references  in  tais  document  to  specific  words  wnicti  are 
tecanical  terms  wita  .neaninjs  specific  to  AISIM  tnat  differ  from 
generally  accepted  definitions  will  appear  wita  an  initial  capi¬ 
tal.  fnis  applies  specifically  to  AISIM  entities. 

EXAMPLE:  process  -  occurrences  of  tms  word  refer  to  tne 

AISIM  entity. 

1.3  ApplicaDle  documents 

fae  following  documents  provide  supporting  information  on  ‘•ae  use 
of  AISIM: 


AISIM  Training  Manual 

AISIM  Jser ' s  Manual 

AI3IM  product  specification 

fne  following  document  provides  supporting  information  on  tae 
examples  described  in  tnis  document. 


AISIM  Evaluation  -  Prel iminary  Report 
Mitre  Worxinvj  paper  23671 
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2. 


AlSlrt  rtetnodolo- 


Experience  in  usinq  discrete  event  simulation  for  conceptual 
analysis  nas  resulted  in  a  procedure  for  Simula  tin  q  systems, 
fnis  procedure  is  called  ''simulation  analysis"  and  nas  been  docu¬ 
mented  in  various  forms  in  simulation  literature.  Since  Aldld  is 
a  discrete  event  simulation  tool,  all  of  tne  steps  in  cne  simula¬ 
tion  analysis  process  apply  to  performing  AIS Id  analysis.  mis 
discussion  on  AlSIrt  metnodoloqy  calls  out  cne  steps  in  cne  AlSId 
simulation  process  and  points  out  no«j  eacn  of  the  steps  is 
specifically  performed.  To  put  this  into  context,  tne  buexqround 
leading  to  tne  development  of  AI3IM  is  described. 


SYSTEM  DEVELOPMENT  STEPS 


CONCEPTUAL 

SYSTEM 

ANALYSIS 


PERFORMANCE 
AND  COSTS 
RESULTS 


ANALYZE 

RESULTS 


SIMULATION  ANALYSIS  STEPS 


Figure  1.  Simulation  Context 


2 . 1  dacttground 

Simulation  is  a  powerful  analysis  technique  used  to  support  con 
ceptual  analysis  in  order  to  specify  requirements  for  a  system, 
fne  qoel  is  co  engineer  a  system  wnich  worxs,  tnat  is,  a  system 
wnicn  will  perform  its  mission. 

fne  first  steps  in  tne  system  development  process  involve  defin 
ing  tne  requirements  for  a  new  system  and  analysing  tnose 
requirements.  fne  ultimate  objective  is  to  produce  tne  system 
specification . 
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i  n  e  uonceptaal  analysis  s cur cs  w  1  c n  a  u ^ 3 . <j ii  of  a  s  y  s — 

Coin,  wnicn  id  based  on  applying  a  poddiole  solution  co  tne  new 
system  requi  r  events .  For  automated  systems  tne  conceptual  deoiqn 
often  dtartd  witn  tne  allocation  of  fanctiond  in  a  system  to  com¬ 
puters.  rnis  id  aone  in  a  fanctional  spec  1 f ica t ion  wnicn  id 
often  an  informal  document  (ROC  --  Requirements  of  operational 
Capaoil  i  ty)  . 

Many  critical  questions  aooat  tne  new  syscem  sarface  uurinq  con¬ 
ceptual  analysis.  Requirements  are  analyzed  for  consistency  ana 
completenedd .  Wnat-if  questions  are  posed  to  determine  if 
r eqai rem.ents  are  attainaDle.  In  tnia  pnase,  tne  analyst  needs  a 
tool  wnicn  can  provide  qaantitative  answers  to  questions  aboac 
tne  conceptaal  system  desiqn. 

Simulation  modellinq  is  a  tecnnique  wnicn  can  provide  a  tool  to 
qive  tne  analyst  tnese  answers.  Simulation  is  oased  on  tne  fact 
tnat  models  can  be  built  wnicn  represent  a  real  system.. 

Responses  to  experiments  conducted  on  tne  model  are  indicative  of 
responses  to  similar  conditions  in  a  real  system.  fnis  provides 
tne  performance  and  cost  daca  tnat  an  analyst  needs  to  analyze  a 
conceptual  desiqn. 

fiie  qoal  is  to  define  tne  requirements  for  tne  system  wnicn  are 
consistent  and  attainable. 


INTERACTIVE  SIMULATION  BY  SYSTEMS  ANALYST 


Fijure  2.  AI3IM  Simulation  process 
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AISIM  is  an  interactive  system  wnicn  is  used  by  tne  systems 
analyst  to  nelp  define  system  requirements.  It  is  used  by  tne 
systems  analyst  to  modei  a  conceptual  desijn.  3y  using  an 
interactive  system  to  ouild  models,  exercise  models,  anu  analyse 
results,  many  questions  about  a  syst  -ns  functional  spec i f i ca t ions 
can  be  resolved  in  a  timely  and  cost  effective  manner. 

AISIM  nas  been  designed  and  built  to  be  used  by  tne  systems 
analyst.  fae  profile  of  this  user  is  muon  different  tnan  taat  of 
a  programmer.  It  is  assumed  that  tne  systems  analyst  is  not  a 
frequent  computer  user.  He  does  not  Know  about  computer  system 
utilities  lixa  text  editors  or  compilers  nor  does  tie  want  to 
learn.  Tnis  implies  taat  tlie  AI5I.V1  user  interface  nas  to  be  a 
simple,  powerful  one,  wnicn  is  easily  learned.  Tne  functions  of 
AISIM  support  rapid  model  buildinq,  modei  runninq  and  model 
analysis . 


Model  buildinq,  model  runninq  and  modei  analysis  are  tae  taree 
Key  activities  in  tne  simulation  process.  Model  buildinq  is  tne 
mappinq  of  a  system  into  a  simulation  model.  Model  runninq  is 
tne  exercisinq  of  tne  model  under  some  test  conditions.  Model 
analysis  is  tne  translation  of  tne  simulation  results  into  mean¬ 
ingful  statements  about  tne  system  to  support  decision  maKinq. 


Inputs  to  tne  AISIM  Simulation  Process 


fae  input  to  a  simulation  effort  comes  from  tne  functional 
specification  of  a  system  IROC) .  Tne  functional  specification  is 
tne  informal  statement  of  tne  system  requirements  wnicn  is 
derived  by  applying  a  solution  to  a  mission  concept.  A  mission 
concept  is  what  needs  to  be  done .  This  has  specific  meaning  in 
tae  context  of  military  operations.  A  military  operation  is 
defined  as  tne  functions  necessary  to  respond  to  threats  and  pro¬ 
vide  defense.  A  solution  is  the  allocation  and  integration  of 
functions  in  tne  operation  so  tnat  tne  mission  will  be  accom- 
pl isned . 

AISIM  is  directed  at  providing  a  tool  to  analyze  systems  in  wnicn 
computers  are  used  to  perform  soma  of  tne  functions.  This  is  in 
tne  context  of  performing  a  mission. 

2.2.1  Mission  Concept  and  Requirements  Tae  mission  concept  is  a 
description  of  tne  functionality  of  tne  system.  fae  mission  con¬ 
cept  maxes  clear  wno  tne  users  of  tae  syscem  are  and  wnat  tne 
system  does  for  tnem. 

Tae  mission  requirements  are  tne  performance  and  loading  charac¬ 
teristics  of  tne  environment  in  wnich  tne  system  satisfying  tae 
mission  concept  operates. 


2.2.2  problem  perspective  fne  proolem  perspective  identifies 
tne  "expected"  areas  of  concern  in  trie  s/stem  ana  refers  to  tae 
particular  viewpoint  an  analyst  taxes  in  looking  at  a  syscem. 
rne  perspective  is  derived  oy  tne  analyst  and  generally  focusses 
on  tne  cr i tical  thread  of  processing  for  a  mission. 

2.2.3  3 ys tern  Description  fne  system  description  is  tne  concep¬ 
tual  system  design  wnicn  is  proposed  to  satisfy  tne  mission 
requirements.  fnis  often  includes  a  system  "sxetcn"  identifying 
tne  major  components  of  tne  system.  Performance  cnaracter istics 
of  tne  major  components  are  also  included  in  tnis  description. 

2 . 3  Preliminary  Analysis 

a  preliminary  analysis  of  tne  system  is  done  to  determine  if 
discrece  event  simulation  is  applicaole  to  tne  proolem  and  to 
justify  tne  use  of  AXSIrt.  Tnis  is  a  screening  process  and  usu¬ 
ally  is  done  very  quickly.  fne  preliminary  analysis  identifies 
tne  solution  approach  to  analyzing  tne  system.  It  is  important 
to  document  tne  decisions  made  early  in  tne  analysis  effort, 
wnicn  is  tne  oojective  of  tnis  step. 

2.3.1  J ustif ying  AISIM  Simulation  fne  first  step  in  AlSIrt  simu¬ 
lation  analysis  is  to  j  ustif/  the  use  of  a  discrete  event  simula¬ 
tion  for  tne  analysis  of  tne  proolem.  Tnis  is  not  too  difficult 
for  an  AlSIrt  user  because  discrete  event  simulation  is  one  of  tne 
most  powerful  analysis  techniques  available.  Using  AI3IM  elim¬ 
inates  much  of  tne  risk  associated  with  using  tnis  technique 
because  it  enables  users  to  build  models  quickly  for  systems 
wnicn  nave  cnaracteristics  applicable  to  AlSIrt.  To  determine  if 
AISIi^  is  applicable,  one  looks  at  tne  system  description  and 
determines  if  tne  system  has  any  of  tne  following  characteris¬ 
tics  : 

1.  Procedural  Operations  -  Processing  in  tne  system  is 
described  by  a  sequence  of  steps. 

2.  Parallel  Processing  -  Any  number  of  processing  steps  can 
occur  simul taneously . 

3.  Resource  Snaring  -  Elements  of  tne  system  are  snared.  fnere 
is  a  discipline  associated  witn  snaring  wnicn  governs  tne 
use  of  a  resource. 

4.  External  Loading  -  Activity  in  tne  system  can  be  initiated 
by  environmental  stresses. 

5.  Interconnected  Network  Communication  -  Activities  in  tne 
system  communicate  tnrougii  defined  cnannels. 

Systems  witn  tnese  cnarac ter  is  tics  are  easily  modelled  witn 
AloIi4. 


Page  6 


fae  nexc  step  in  justifying  the  use  of  AISIM  is  to  determine  if 
it  is  tne  test  cnoice  of  available  tools  anu  techniques. 

Considerations  for  this  determination  are  tae  following: 

Reasons  for  using  AISIM 

1.  Tne  AISIM  user  is  a  systems  analyst.  AISIM  can  be  learned 
very  quickly.  Features  of  AISIM  enable  the  user  to  build  a 
model  in  a  friendly  environment. 

2.  AISIM  enables  tne  user  to  build  models  quickly. 


3.  AISIM  provides  automatic  standard  model  documents t ion . 

4.  AISIM  models  are  easily  inteqrated  with  otner  AISIM  models. 
AISIM  allows  models  to  be  merged  together  or  saved  in  a 

1 ibrary . 

5.  AISIM  nas  specific  features  for  networx  modelling. 

Reasons  for  NOT  using  AISIM 


1.  AISIM  requires  tae  use  of  a  SP2647A  terminal  used  in  an 
interactive  node. 

2.  aISIm  models  are  built  from  a  hi gn  level  description  of  a 
system.  In  order  to  modal  a  system  at  a  very  low  level  some 
of  tne  power  of  AISIM  is  neutralized. 

3.  AISIM  models  can  only  be  run  on  computers  on  which  AISIM  is 
hosted . 

Deciding  wnetner  AISIM  is  appropriate  usually  is  done  based  on 
tnese  cypes  of  considerations.  Bencnmarks  conducted  on  AISIM 
show  that  users  of  AISIM  can  be  trained  to  be  expert  users  in  a 
matter  of  days.  Models  done  using  AISIM  nave  been  saown  to  be 
built  in  substantial ly  less  time  tnan  doing  the  same  model  in  a 
simulation  programming  language. 

2.3.2  Def ine  the  problem  and  Ob j  actives  having  decided  tnac 
simulation  is  appropriate  to  tne  analysis  of  a  conceptual  design 
and  that  the  input  data  described  in  section  2.2  is  obtainable, 
the  first  activity  which  an  AISIM  user  performs  is  to  define  tae 
problem  and  state  the  objectives  of  tne  modelling  efforc.  mere 
are  tnree  steps  in  tnis  whicn  produce  a  statement  of  tae  problem 
with  a  solution  approacn.  It  is  important  that  the  statement  be 
written  as  a  document  to  provide  visibility  so  tnac  both  tae 
AISIM  analyst  and  model  reviewers  Know  what  is  to  be  determined 
by  tae  AISIM  modelling  effort. 
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2. 1.2.1  Defining  tne  P  r  odI  em  An  All  IM  model  io  a  simplified 
aostraction  of  a  system.  Many  elements  ana  components  of  tne 
system  will  Da  ignored  in  tne  model.  In  defining  cna  proolem, 
tne  aISIM  analyst  states  tne  "expected"  areas  of  concern  found  in 
tne  proolem  perspective,  including  tnose  areas  whion  will  oe 
addressed  in  tne  model  and  tnose  wnicn  will  not.  For  tne  omitted 
areas,  j us ti f ica tion  snould  be  given  way  tney  are  not  to  oe 
audressed.  In  defining  tne  problem,  tne  AISIM  user  documents  any 
assumptions  wnicn  are  made  about  tne  systems  mission.  Tne 
assumptions,  of  course,  snould  be  consistent  witn  tne  mission 
concept.  Often,  tne  assumptions  address  "noles"  in  tne  mission 
concept . 

fne  ooundaries  of  a  model  refer  to  tne  level  of  detail  of  tne 
AISIM  model  to  represent  tne  elements  botn  witnin  tne  system  and 
external  to  tne  system.  In  determining  tne  ooundaries  of  tne 
model,  tne  AISIM  user  maxes  a  preliminary  pass  at  mapping  tne 
components  of  tne  system  into  simulation  entities.  Specif ically, 
it  snould  be  determined  wnicn  components  of  tne  system  are  to  be 
modelled  oy  matnematical  functions  and  wnicn  are  to  be  modelled 
by  AIS1M  entities.  Also,  tne  determination  of  wnat  elements  of 
tne  system  will  be  modelled  as  Loads  and  wnat  elements  will  oe 
modelled  by  more  detailed  structures  lixe  Processes  snould  be 
determ ined . 

2. 3. 2. 2  Defining  tne  Simulation  Objectives  A  clear  statement  of 
tne  objectives  of  tne  aISIM  modtel  snould  be  written.  rnis  state¬ 
ment  includes  tne  questions  about  tne  system  wnicn  tne  AISIM 
model  will  answer.  Tne  statement  of  oojective  provides  visioil- 
ity  for  wnat  tne  simulation  will  accomplish. 

2 . 4  Design,  plan  and  Construct  tne  Model 

Designing  and  planning  a  model  are  tne  activities  a  modeller  per¬ 
forms  to  come  up  witn  a  seneme  for  implementing  a  model  of  a  sys¬ 
tem.  A  model  design  is  tne  "document"  wnicn  a  modeller  produces 
wnicn  identifies  tne  mapping  of  components  of  a  system  into  or 
onto  components  of  a  modelling  tool.  A  model  plan  is  tne  time 
sequence  steps  performed  to  implement  the  model.  Constructing 
tne  model  is  the  activity  tne  modeller  performs  to  implement  tne 
mapping  using  tne  modelling  tool. 

fne  model  design  lays  out  the  model  structure.  fne  model  struc¬ 
ture  siiows  tne  logical  allocation  of  functions  in  tne  system  in 
relation  to  functions  in  tne  model.  mis  structure  snould  loox 
similar  to  tne  system  structure  in  the  system  description  wicn 
one  exception.  fne  model  structure  includes  a  representation  of 
tne  system  environment  as  a  function.  That  is,  tne  load  generat¬ 
ing  part  of  tne  model  is  shown. 

fne  first  step  in  designing,  planning  and  constructing  a  model  is 
to  determine  tne  model  structure  and  use  that  as  tne  initial 
model  design. 
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designing,  planning  and  constructing  a  model  are  activitie 
are  done  iteratively.  mis  is  not  noticeaoly  different  tn 
plan,  design  and  build  steps  in  developing  a  system.  Wnen 
developing  a  system,  tnougn,  it  is  very  important  to  nave 
stable  system  design  before  starting  to  build  components  o 
system.  fnis  is  because  tne  resources  required  to  build  c 
ponents  are  usually  costly  so  tnat  it  is  desirable  to  use 
efficiently.  Using  AISIM,  a  model  can  be  constructed  very 
quicxly  wi  tn  very  little  expense.  fnerefore,  it  is  possio 
start  tne  model  building  process  before  completing  a  model 
witn  tne  Knowledge  tnat  if  part  of  tne  model  is  incorrect, 
easily  be  modified  at  some  time  in  tne  future.  Tne  goal  i 
"lit  sometning  running "  wnicn  models  some  part  of  tne  syst 
fnis  provides  early  results  so  tnat  feedback  on  tne  modell 
approacn  can  oe  obtained  as  soon  as  possible.  In  conjunct 
with  ouilding  an  initial  model  prototype,  a  plan  is  develo 
implementing  tne  complete  model  of  tne  system  based  on  tne 
structure . 
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f  tne 

om- 

tnem 
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Witn  tne  model  structure  a  model  design  includes  taDles  and 
cnarts  wnich  snow  now  tne  components  of  a  system  map  to  simula¬ 
tion  entities  and  now  tne  simulation  entities  are  related.  rne 
model  plan  describes  now  models  of  components  of  the  complete 
system  can  be  integrated  into  a  complete  system  model.  fne  model 
plan  is  produced  as  tne  model  structure  is  determined.  Tne  plan 
is  updated  wnen  necessary  as  a  result  of  suDsequent  model  design 
and  construct  activities. 


Tne  designing  and  building  of  AlSIrt  models  is  an  iterative  pro¬ 
cess.  First  a  component  of  the  system  is  selected.  A  model  is 
built  of  tnat  component.  This  is  called  a  submodel.  fhe  submo¬ 
del  is  built  and  verified.  Then  anotner  component  of  tne  system 
is  selected.  Sacn  submodel  is  built  and  integrated.  This  con¬ 
tinues  until  the  complete  model  of  tne  system  is  built  whicn 
satisfies  tne  problem  definition.  At  each  iteration  it  may  be 
necessary  to  modify  the  submodels  previously  built  to  effect  tne 
integration. 

It  is  expected  at  tnis  step  tnat  an  AlSIrt  user  will  make  use  of 
submodels  wnicn  nave  already  been  built  and  stored  in  tne  AISM 
library.  Since  many  systems  have  similar  components,  it  is  often 
possible  to  extract  a  submodel  from  anotner  model  and  witn  only 
slignt  modifications,  include  it  in  a  new  model. 

2.5  Exercise  tne  Model 

Exercising  tne  model  is  the  activity  a  modeller  performs  to 
stress  tne  model  system  in  order  to  obtain  performance  results. 
Tne  model  is  exercised  to  first  verify  tnat  it  cycles  correctly, 
and  second  to  answer  questions  directed  at  tne  system  conceptual 
design. 

Using  AX 5 It4 ,  a  modeller  describes  tne  environment  in  whicn  tne 
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model  system  is  to  operate  in  terms  of  a  Scenario.  Scenario 
definition  snould  be  carefully  cnosen.  Wnen  verifying  a  model, 
tne  Scenario  nas  to  be  easily  understood.  mat  means,  it  must 
qenerace  a  load  on  tne  system  wnicn  can  be  traceu,  if  necessary, 
to  deou-j  loqic  errors  wnicn  nave  oeen  included  in  tne  model  by 
mistaxe.  Wnen  supporting  decisions  about  tne  system  design,  tne 
Scenario  must  represent  tne  actual  environment  in  wnicn  tne  sys¬ 
tem  is  expected  to  operate. 

Verifying  tne  moael  is  tne  activity  a  modeller  performs  to  insure 
tnat  tne  model  wnicn  is  built  executes  correctly.  i'nis 
corresponds  to  deDuqqinq  a  program  and  must  be  done  to  eacn  sub¬ 
model  as  it  is  ouilt.  Normally,  wnen  one  deDuqs  a  program,  it  is 
sufficient  to  test  tne  single  tnread  execution  of  tne  program 
tnrouqn  all  of  its  tnreads  of  processing.  yenfyinq  a  model  or  a 
suDmodel  is  somewnat  more  difficult  tnan  deQuqqinq  a  program 
oecause  one  nas  to  test  tne  time  varying  execution  of  tne  model 
in  a  ip.ul  ti-processinj  sense.  mis  is  done  first  oy  running  a 
simulation  on  tne  model  usinq  simple  Scenarios  wnicn  stress  tne 
model  in  predictable  ways.  Tne  model  is  verified  oy  comparing 
results  of  tne  simulation  witn  expected  results.  Wnen  results  of 
tne  simulation  do  not  matcn  expected  results,  tnen  tnere  is 
eitner  a  proolem  witn  tne  model  or  tne  expected  result  is 
incorrect.  A  model  is  verified  wnen  a  resolution  Detween 
expected  results  and  computed  results  for  all  verifying  Scenarios 
is  completed. 

Wnen  verifying  a  simulation,  it  is  advisable  to  eliminate  all 
randomness  from  a  model.  This  way  it  is  possible  to  compute 
accurate  expected  results  and  define  a  scenario  wnicn  stresses 
tne  model  in  sucn  a  way  to  produce  tne  results.  Tnere  are  two 
types  of  Scenarios  generally  used  to  verify  AISIM  models  -  single 
tnread  and  multiple  tnread. 


2.5.1  Single  Thread  Scenarios  a  single  tnread  Scenario  is  one 
wnicn  exercises  tne  sequential  loqic  of  tne  model  witnout  ena¬ 
bling  resource  contention  or  mul ti-processinq  loqic.  A  single 
tnread  Scenario  defines  one  path  tnrouqn  tne  model  loqic. 

Results  from  running  a  simulation  usinq  a  sinqle  tnread  scenario 
snould  verify  tnat  all  delay  times  and  arithmetic  computations 
are  correct. 


2.5.2  ,4ul  tiple  Tnread  Scenarios  A  multiple  tnread  Scenario  is 
one  wnicn  exercises  tne  resource  contention  and  mul ti-processinq 
loqic  of  a  model.  A  multiple  tnread  Scenario  defines  many  patns 
tnrouqn  tne  loqic  witn  simultaneous  Process  executions.  A  mul¬ 
tiple  tnread  Scenario  snould  oe  set  up  to  stress  tne  model  system 
in  a  very  reqular  way  so  tnat  expected  results  can  be  determined. 


2.5.3  Analysis  Scenar  ios  Once  the  simulation  nas  been  verified 
so  tnat  a  reasonable  level  of  confidence  exists  that  it  is 
representative  of  tne  problem,  analysis  Scenarios  are  defined  to 
determine  tne  performance  of  tne  system  under  representative  sys¬ 
tem  loading  conditions.  The  data  for  defining  tne  system  loading 
conditions  is  generally  derived  from  tne  requirements  of  opera¬ 
tional  capability  or  from  observation  of  existing  systems  per¬ 
forming  similar  missions.  Associated  witn  eacn  analysis 
Scenario,  tne  analyst  should  classify  tne  Loads  so  tnat  perfor¬ 
mance  of  tne  system  produced  by  tne  simulation  can  De  tracxed  to 
tne  Scenario. 


Anal 


Resul ts 


AISIM  produces  two  standard  outputs,  interactive  plots  of  tne 
instantaneous  simulation  data  and  statistical  summaries  of  all 
model  entities.  An  AISIM  user  uses  botn  of  tnese  to  analyze  the 
dynamics  of  tne  modelled  system.  Interactive  plots  of  tne  simu¬ 
lation  data  are  used  to  determine  if  the  simulation  reached  a 
steady  state,  tnat  is,  no  infinite  queueing  or  otner  system 
bottleneck.  If  tne  system  did  not  reach  a  steady  state,  tnen 
mucn  of  tne  data  in  tne  statistical  summary  can  not  be  taken  at 
face  value;  e.g.,  statistics  on  average  performance  are  not 
valid.  For  eacn  simulation  run,  a  modeller  snould  review  all 
results  and  resolve  any  question  about  the  system  dynamics  which 
is  raised  in  his  mine. 


Analyzing  simulation  results  is  a  Challenging  task.  To  do  tnis 
well  ic  is  necessary  to  understand  the  Scenario  stressing  the 
modal  and  now  it  relates  to  questions  about  tne  system  design. 
Based  on  tne  Scenario,  the  analyst  maps  tne  results  of  tne  simu¬ 
lation  experiment  into  concrete  statements  about  tne  syscem  per¬ 
formance  in  actual  operation. 

2.6.1  Identify  Measured  Performance  Statistics  AISIM  outputs 
are  standardized.  Tnis  has  tne  advantage  tnat  tne  AISIM  user 
needn't  concern  nimself  witn  formatting  reports  or  worry  about 
tne  validity  of  computations.  On  the  other  nand,  standardized 
reports  may  not  provide  the  user  witn  results  in  a  form  directly 
related  to  tne  wording  of  performance  questions  about  the  system. 
Because  of  tnis,  it  is  necessary  to  identify  tne  statistics  in 
tne  AISIM  statistical  summary  wnicn  are  most  relevant  to  tne 
stated  question. 

2.6.2  7a 1 idata  tne  Model  Validation  refers  to  determining 

whether  a  model  accurately  represents  a  system.  Most  AISIM 

models  are  validated  tnrougn  a  review  process,  where  the  design 
and  structure  of  tne  model  are  presented  witn  results  to  people 
Knowledgeable  in  tne  system  modelled.  The  assumptions  of  tne 
model  should  be  described  in  detail.  The  model  can  be  considered 

to  be  validated  "by  face"  if  no  major  objections  or  issues  are 

raised  in  tnese  reviews. 
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A  simulation  can  be  validated  in  part  by  analytic  me^ns. 

Resource  utilization  is  tne  simplest  calculation  wnicn  can  oe 
done  oy  nan d  anu  compared  to  simulation  generated  results. 
Resource  utilization  is  a  function  of  tne  "arrival  race"  and  tne 
Resource  "service  time"  calculated  usiny  yueueiny  tneory.  Tne 
“arrival  rate"  corresponus  closely  to  tne  mean  time  for  proiess 
triyyeriny  in  an  AlSIi'i  Load.  fne  "service  time"  corresponds  to 
Action  delay  times  duriny  wnicn  AXSlri  Resources  are  allocated. 
Resource  utilization  is  reported  under  ucsource  rf  a JS L  statistics 
in  tne  AlSXrt  Resource  Report. 

Companny  analytic  results  to  simulation  yenerated  resul  ts  pro¬ 
vides  an  initial  level  of  confidence  of  tne  validity  of  tne  aiodel 
if  resul ts  matcn  closely.  plots  of  simulation  yenerateu  data  can 
support  tne  simulation  results  reported  in  tne  AlSIrt  Report.  For 
tnis  manual,  tne  example  proolems  will  oe  validated  oy  companny 
resales  to  analytic  ones. 


Example  1  -  Communica tion  Network 


Example  1  id  representative  of  a  cowman  ice c ion  system  consisting 
of  many  nodes  which  communicate  tnrougn  a  subnet  of  switen  pro¬ 
cessors.  It  is  typical  of  tne  type  of  system  addressed  during 
tne  conceptual  pause  of  command,  control  and  commun ica c ion  system 
acquisition.  me  example  demonstrates  tne  use  of  aISIM  to 
analyze  a  messaqe-dr iven  communication  system  consisting  of  many 
nodes  wi tn  complicated  routing  strategies. 

3 . 1  Input 

3.1.1  Mission  Concept 

Many  airoases  are  connected  to  Headquarters  tnrouqn  a  communica¬ 
tion  network.  The  mission  of  tne  system  is  to  provide  communica¬ 
tion  oetween  tne  oases  and  neadqua r te r s .  Tne  "users"  of  tnis 
system  can  oe  identified  as  tne  users  wisninq  to  communica te . 
Communication  is  implemented  by  electronic  means  usinq  messaqe 
switeninq  processors  connected  in  a  subnet. 

Tne  messaqe  switeninq  processors  direct  tne  data  flow  throuqn  tne 
suonet  and  control  tne  transmission  of  messaqes  between  nodes  and 
across  communication  cnannels. 

Airoases  are  tne  oriqin  and  destination  of  messaqes.  Messaqes 
qenerated  at  airbases  request  functions  to  oe  performed  at  head¬ 
quarters.  Headquarters  respond  to  requests  Dy  performinq  tne 
requested  function.  In  some  cases  data  is  returned  to  tne  air¬ 
oases  qeneratinq  requests. 

A  command  Headquarters  is  tne  destination  for  all  messaqes  and  is 
tne  source  of  display  output  messaqes. 


3.1.2  Problem  Perspective 

A  study  of  tne  followinq  desiqn  elements  is  basic  to  the  system 
to  be  modelled. 

1.  Network  fopoloqy  -  fnere  are  many  different  conf iqurations 
of  tne  nardware  elements  of  tnis  system.  Dependinq  on  tne 
pnysical  distances  and  equipment  used,  tnere  may  be  few  or 
many  subnet  switen  processors. 

2.  Channel  Communications  -  Channel  communications  are 
described  in  terms  of  capacity  (cnaracters/sec)  and  protocol 
(naif  or  full  duplex)  . 

3.  Nodal  Processinq  -  Associated  witn  the  airbases  and  head¬ 
quarters  are  processors  which  perform  messaqe  qeneration  and 
processinq.  Associated  witn  subnet  switen  nodes  are  proces¬ 
sors  waicn  perform  messaqe  routinq. 


4. 


Message  Types  and  Attrioutes  -  .ijosajea  are  aeacr  iOao  oy 
type  (data  aisplay  request,  narucopy  display  request,  aara- 
aopy  data)  eacn  of  wnicn  nas  tne  d i sting ai suing  attribute  of 
length  in  cnaraccers. 

Tne  expected  area  of  concern  in  this  system  focusses  on  tne 
resource  snaring  of  subnet  processors  and  common ica cion  cnannels. 
Tne  performance  measures  to  be  obtained  from  tne  model  are  tne 
following : 

1.  Communications  jueue  Time  -  For  eacn  cnannel  in  tne  communi¬ 
cation  networx,  tne  time  messages  waic  at  subnet  processing 
nodes  to  gain  access  to  a  communication  cnannel . 

2.  Communications  Cnannel  Jueue  Leng tn  -  for  eacn  cnannel,  tne 
number  of  messages  waiting  at  subnet  processing  nodes  for 
access  to  a  communication  cnannel. 

3.  processor  jueue  Time  -  For  eacn  subnet  node  processor,  tne 
time  messages  wait  to  be  routed  or  processed. 

4.  Processor  Jueue  Length  -  For  eacn  subnet  node  processor,  tne 
number  of  messages  waiting  to  be  routed  or  processed. 

5.  Communication  Cnannel  Utilisation  -  Fne  average  use  of  a 
communications  cnannel  for  a  unit  time. 

5.  Processor  Utilization  -  Tne  average  use  of  a  processor  for  a 
unic  time. 

Tne  critical  tnread  is  tne  sequence  of  events  for  transmitting 
process  requests  from  source  to  destination  nodes. 

3.1.3  5 ystem  Descr iption  Tne  following  description  represents  a 

communication  system.  fne  system  is  described  oy  a  proposed  net¬ 
worx  design  and  a  definition  of  tne  system  traffic  load. 


3. 1.3.1  Proposed  Networx  Design  fne  networx  is  described  oy  its 
topology,  cnannel  capacities,  and  routing  tables.  fne  suggested 
networx  topologies  incorporate  3,  5,  and  7  subnet  nodes.  Figure 
3  illustrates  tnese  subnet  topologies  and  shows  tne  sources  and 
destinations  of  message  traffic.  fne  tnree  types  of  messages  to 
be  processed  by  tnis  necworx  are  data  messages,  display  request 
messages,  and  display  output  messages.  Tne  ds  represent  bases 
wnere  messages  may  originate  and  terminate  and  wnere  naracopy 
display  messages  may  terminate.  Tne  Hjs  represent  neadquarters 
wnicn  also  originate  and  terminate  message  traffic  anu  in  addi¬ 
tion  nave  a  grapnic  display  capability. 

Tne  Cdd  represents  tne  command  headquarters  and  is  a  destination 
for  all  messages,  but  it  is  only  tne  source  of  display  output 
messages.  It  is  tne  only  source  of  display  output  messages,  fnat 
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is,  it  is  ne^er  tne  source  of  daca  messages  and  it  is  always  tne 
source  of  display  output  massages.  fne  CdJ  contains  a  display 
processing  capaoiiity  wnicn  accepts  a  display  request  message, 
generates  a  display  output  message  (nardcopy  or  jrapuxc  formacj 
and  sends  it  to  tne  originator  of  tne  display  request. 

Tne  Ss  represent  subnet  nodes  and  perfor.n  only  message  switching 
functions.  Ss  are  never  tne  sources  or  destinations  of  any  mes- 
saqe  traffic.  fne  detennination  of  tne  number  and  location  of 
tnese  subnet  nodes  is  a  major  reason  for  tne  development  of  tais 
u.odel . 


3. 1.3. 1.1  Message  flow  Messages  are  transmitted  in  maximum  size 
blocks  of  4UU0  characters  and  flow  from  an  originating  d  or  H*)  to 
its  associated  S,  tnrougn  tne  S  network  to  tne  destination  S,  and 
finally  to  tne  destination  8,  HJ,  or  CdJ.  Originating  messages 
can  be  eitner  data  messages  or  display  request  messages.  fne 
data  message  flow  is  as  just  described.  a  display  request  mes¬ 
sage  can  originate  at  any  B  or  at  eitner  rij  and  terminate  at  tne 
CHJ  wnere  tne  request  is  processed.  A  display  output  message  is 
generated  at  tne  CBJ  and  tne  message  is  transmitted  tnrougn  tne  3 
network  back  to  tne  originating  B  or  rij. 

3. 1.3. 1.2  Routing  Routing  tnrougn  tne  network  will  be  in  accor¬ 
dance  witn  tne  taoles  saown  in  fable  2  for  tne  three  proposed 
network  topologies.  Tne  coordinates  in  each  table  are  tne 
current  node  and  tne  destination  node.  Tne  intersection  of  tnese 
ordinates  contains  the  number  of  tne  next  node  to  wnicn  tne  mes¬ 
sage  is  to  oe  transmitted. 
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3. 1.3. 1.3  Cnanne 1  Capac i  ci es  fne  effect  of  differ one  onannel 
capacities  is  to  be  examined  in  detail  for  tne  case  1  net.vorx 
topology.  Figure  5  jives  tne  different  cnannel  transm  iss  ion 
races  for  eacn  analysis  run.  It  is  assumed  tnat  all  cnanneis  are 
full  duplex  <vnicn  ineans  tnat  tiiey  can  transmit  information  in 
Doth  directions  simul caneousl y  at  tne  specified  bit  rates. 

3. 1.3. 1.4  Nodal  P  rocess  inj  Eacn  node  in  tne  net^orx  nas  a  pro¬ 
cessor  associated  with  it  to  perform  its  message  switeninj  func¬ 
tions.  Tne  networx  model  snould  incorporate  delays  for  process¬ 
ing  (ootn  queueing  time  and  processor  time)  at  tne  3,  d J ,  ana  Cdd 
nodes.  Figure  5  contains  cnaracter  processing  rates  for  tne 
various  nodal  processors.  Storage  for  eacn  processor  can  ini¬ 
tially  oe  assumed  to  be  1,1100,000  Dytes  but  snould  be  a  variable 
wnicn  can  oe  adjusted  as  necessary. 
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Data 

a 

Compr. 

S  -  S 
Channels 
(kb/s) 

S  -  HQ 
Channels 
(kb/s) 

S  -  CHQ 
Channels 
(kb/s) 

S  -  B 
Channels 
(kb/s) 

No 

19. 2b 

40.8 

230.4 

4.8 

Yes 

19. 2b 

40.8 

230.4 

4.8 

Yes 

9 . 6C 

9.6 

230.4 

9.6 

Yes 

9.6 

9.6 

230.4 

9.6  | 

Yes 

9.6 

9.6 

230.4 

4.8 

Yes 

9.6 

9.6 

230.4 

9.6 

Yes 

9.6 

9.6 

230.4 

9.6 

Data  Compression  factor  Is  50  percent. 

All  S  -  S  Channels  except  4-7,  which  is  40.8  kb/s. 
All  S  -  S  Channels  except  4-7,  which  is  19.2  kb/s. 


Figure  5.  Example  1  Channel  Capacities 

Processor  Variables 


Processor 

Processing  Rate 

S  Processor 

HQ  Processor 

CHQ  Display  Processor 

CHQ  Display  Processor 

80  /us/char 

80  fd s/char 

100  //s/char  (hardcopy) 

280  //s/char  (graphic) 

Figure  6.  Example  1  processor  /ariaolas 


3. 1.3. 2  Message  fraff ic  Message  input  traffic  for  tne  networx 
model  consists  of  data  messages  and  display  request  messages. 
Tne  cnaracteristics  of  these  messages,  i.e.,  lengtn,  input  or 
output  rate,  and  number  of  destinations  are  given  in  tne  Messag 
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ftuffic  Ciid  rdc  cor  ioCiCi  Table,  Fijure  7.  Messages  are  to  oe  sta¬ 
tistically  generates!  by  tae  model  wicn  exponential  in  c.e  r-ar  r  i  val 
times  (i.e.,  a  Poisson  arrival  patcern).  1’ne  message  input  rate 
snown  ia  a  total  figure  from  all  sources  and  ia  discriouteu  ran¬ 
domly  by  source  aa  snown  in  Figure  7.  Message  deatinationa  are 
aelected  according  to  tne  traffic  iratricea  presented  in  Figure  3. 
data  messages  eaca  nave  three  deatinaciona  wnicn  differ  according 
to  source  node  aa  snown  in  tne  data  message  traffic  matrix.  An 
"X"  in  tne  matrix  indicatea  a  destination  for  that  message 
source.  Tne  two  l/2s  indicate  tnat  tne  messages  are  co  be  sp^ic 
equally  oetween  tnese  two  deatinationa.  Tnat  is,  for  all  data 
messages  originating  from  a  a  connected  to  SI,  one  copy  will 
always  go  to  anotner  a  connected  to  S7,  one  copy  will  always  go 
to  CiiJ-10,  and  tne  tnird  copy  will  alternately  oe  delivered  to 
rld-3  or  HJ-9. 

Display  request  messages  may  originate  from  an  HD  or  a  a  con¬ 
nected  to  any  S  and  tnat  they  are  always  addressed  to  tne  CHD 
(see  Figure  3).  Messages  originating  at  the  CHD  are  only  display 
output  messages  generated  in  response  to  a  display  regueat  and 
are  addressed  only  to  tne  a  or  rid  that  originated  tne  regueat. 

Display  output  messages  vary  in  lengtn  depending  upon  tne  type  of 
display  reguest — nardcopy  or  grapnic.  Messages  destined  for 
nardcopy  printer  output  are  6300  cnaracters  in  lengtn  wnile  taose 
oeing  displayed  on  a  grapnic  device  are  10,000  cnaracters  in 
lengtn.  Tne  time  reguired  for  tne  processing  of  tne  regueat  and 
tne  generation  of  the  display  must  be  simulated  at  tne  CHD.  fig¬ 
ure  6  contains  the  processing  rate  variables  for  botn  of  tnese 
f unc  tions . 

Tne  model  routes  messages  over  tne  pre-defined  patns,  creates 
message  delays  caused  Dy  line  and  node  gueues,  and  provides  a 
statistical  output  of  the  specified  networx  parameters.  Section 
2.2  illustrates  the  gueueing  and  process  functions  wnicn  tne 
model  must  produce.  A  message  originates  at  a  6,  HD,  or  CHD  node 
where  an  output  gueue  is  established  and  tne  output  gueue  time 
(Tog)  is  noted  for  tne  output  channel .  The  transmission  time 
(ft)  is  accounted  for  to  tae  S  node,  and  a  processor  gueue  time 
(fpg)  and  processor  service  time  (Tp)  are  recorded.  Tne  message 
is  cnen  put  on  one  or  more  output  gueues  where  the  output  gueue 
time  (fog)  and  tne  transmission  time  (ft)  to  tne  next  node  (3,  5, 
HD,  or  CHD)  is  calculated.  No  statistics  are  recorued  for  tne 
final  destination  node  with  the  exception  of  display  reguest  mes¬ 
sages  wnicn  go  to  tne  CHD  and  wnicn  cause  tne  generation  of  a 
display  output  message.  fhe  time  to  generate  this  message  must 
be  accounted  for  in  tne  CHD  processor.  fne  display  output  mes¬ 
sage  is  tnen  treated  aa  a  new  message  wnicn  is  placed  on  tne  out¬ 
put  gueue  at  tne  CHD  destined  for  b7  and  this  message  is  pro¬ 
cessed  tnrougn  tne  networx  in  tne  same  manner  as  any  message. 
However,  tne  total  message  transit  time  for  a  display  message 
will  be  tne  time  from  origin  of  the  display  reguest  to  delivery 
of  tne  display  output  to  tne  originator  of  tne  reguest. 
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Message  Traffic  Characteristics 


Message 

Type 

Mean 
Message 
Lengthb 
(8-bit  Chars. ) 

Message 

Rate 

(Msg. /Sec) 

Input 

Data  Message 

750 

.  517c 

Messages 

Display  Request 

200 

.  583c 

System 

Generated 

Display  Output 
Hardcopy 

6,300 

.510* 

Outputs3 

Display  Output 
Graphic 

10,000 

.07?* 

Number  of 
Destinations 

3 


Generated  in  response  to  Display  Requests. 

’Exponential  distribution.  Length  is  without  data  compression. 
Maximum  length  per  message  partial  is  4000  characters. 

'Poisson  arrival  pattern.  Sources  randomly  distributed  according 
to  table  1-6. 

'Message  destination  generated  according  to  sources  specified  in 
table  1-6. 

Destinations  specified  in  traffic  matrix  tables. 


Message  Traffic  Sources 

Distribution  of  Message 


Message  Type 

S 

Sl-7 

Data  Messages 

94 

Display  Request 

Hardcopy  (Xitput 

82 

Graphic  Output 


CHQ-10 


Figure  7.  ,4essa~je  Traffic  Cnar ac tar ist ic; 
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3.2.1  Jus tif /ing  AISIM  Simulation  AISIM  is  appiicaole  to  tnxs 
problem.  The  cnaracter istics  of  tne  system  map  well  into  AISI.'l. 

1.  Procedural  Operations  -  Messages  originating  at  a  source  and 
routing  tnrougn  tne  network  follow  a  sequence.  fne  sequence 
is  described  by  tne  following  steps: 

Step  1  Message  created  at  a  source. 

Step  2  Message  routed  througn  network  tnrougn  subnet 
swi ten  processors  over  commun icat ions  chan¬ 
nels. 

Step  3  Message  received  and  processed  at  destina¬ 
tion  . 

Step  4  Response  returned  when  appropriate. 

This  sequential  operation  is  followed  for  all  messages. 

2.  Parallel  Processing  -  Any  of  the  subnet  nodes  can  be  simul¬ 
taneously  handling  messages. 

3.  Resource  Snaring  -  Subnet  nodes  and  communication  cnannels 
are  snared,  a  node  may  nave  many  messages  to  process  at  any 
instant.  Many  messages  may  be  ready  to  be  transmitted  over 
a  communication  channel. 

4.  External  Loading  -  Tne  loading  on  the  network  is  described 
as  message  traffic  characterized  by  a  message  rate  in  terms 
of  messages  per  second.  Tnis  is  snown  in  the  Message 
Traffic  Characteristics  Table,  Figure  7.  Messages  are  dis¬ 
tributed  by  percentages  over  nodes.  Each  message  is 
representative  of  a  data  processing  request  suomitted  by  a 
user  to  the  air  base  computer  processor.  Tne  external  load¬ 
ing  on  tne  communication  is  subtracted  from  tne  expected  use 
of  tne  airbase  computer. 

5.  Interconnected  Network  -  Different  network  conf igurations 
are  posed  as  tne  key  area  of  interest  in  tnis  system. 

3.2.2  problem  Definition 

The  problem  definition  for  Example  1  can  be  stated  as  "represent¬ 
ing  tne  important  elements  of  the  described  system  by  modelling 
entities".  The  selection  of  tne  elements  of  the  system  to  be 
represented  is  made.  This  is  described  in  tne  following  state¬ 
ments  . 
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1.  All  processors  in  tae  s/s  tern  will  be  represenceu.  Proces¬ 
sors  will  nave  cnarac ter istic  attributes  for  comp uting  pro¬ 
cessing  delays  based  on  tne  cycle  speed  of  tne  processor  ana 
cae  number  of  cnaracters  processed.  processor  ase  is 
governed  by  FIRST  IN  -  FIRST  OUT  queueing  logic. 

2.  All  communication  linxs  in  tne  system  will  be  represented. 
Linns  will  nave  tne  cnaracter  istics  of  communication  cnan- 
nels  for  computing  utilization  of  channels  oasec  on  baud 
rate  expressed  in  cnaracters  per  second.  Linns  will  be 
governed  oy  FIRST  IN  -  FIRST  OUT  queueing  logic. 

3.  The  connectivity  of  tne  networn  will  be  representeu  by  a 
matrix  equivalent  to  tne  routing  taDles  in  tne  system 
description . 

4.  Message  routinq  will  be  modeled  for  forwardinq  messaqes  in 
tne  system  from  a  source  node  to  a  destination  node.  Tne 
messaqe  forwardinq  will  tane  into  account  tne  processing  and 
queueinq  of  messaqes  through  the  networn.  Messaqes  will  be 
represented.  Each  messaqe  will  nave  a  separate  instance  for 
eacn  occurrence. 

5.  Data  compression  will  be  represented  by  modifying  tne  attri¬ 
butes  of  tne  instances  of  messaqes.  This  will  be  modeled  by 
tne  AISIM  Processes. 

6.  different  simulation  runs  will  exercise  tne  model  accordinq 
to  tiie  different  Cases  of  networn  topology  and  loading.  A 
simulation  will  consist  of  an  architecture  for  tne  system,  a 
related  legal  path  taole  for  the  architecture  and  a  message 
loading  modeled  by  the  introduction  of  messages  into  tne 
system  at  nodes  over  time. 

Tne  AISIM  model  of  tne  communication  networn  will  address  all  tne 
elements  of  tne  system,  descrioed  in  tne  system  description,  witn 
two  noticeaDie  exceptions.  Since  no  airbase  has  different  attri¬ 
butes  than  any  other  and  the  loads  are  specified  accordinq  to  S 
nodes,  it  is  not  necessary  to  model  the  airbase  processors  as  35 
nodes.  Rather  tne  loads  can  be  generated  from  one  airbase  node 
per  3  node,  representing  many  airbases.  There  are  two  ways  to  do 
th  is. 

dne  way  is  to  specify  that  a  number  of  resource  units  (seven  for 
case  1)  is  to  oe  associated  witn  eacn  airbase  load  noue.  Also 
eacn  linx  between  an  airbase  and  a  subnet  switch  S  node  can  oe 
considered  to  be  seven  channels.  Using  this  scheme,  tne  load  for 
eacn  airbase  can  be  generated  oy  increasing  tne  message  genera¬ 
tion  at  a  base  by  a  factor  of  seven.  Tnis  would  not  effect  tne 
loading  on  tne  subnet  switcn  nodes  and  headquar ters . 

A  second  way  to  do  this  is  to  increase  tne  processinq  capacities 
of  tne  airoase  processor  and  the  associated  channels,  wnicn 


prevents  queueing  at  tne  air  base  processor  from  effecting  tne 
load  on  tne  subnet  switch  nodes. 

For  tne  purposes  of  this  model,  tne  second  alternative  is  suffi¬ 
cient.  It  is  selected  because  it  simplifies  the  model  without 
invalidating  it. 

Tne  second  exception  to  tne  system  definition  involves  tne  model¬ 
ling  of  processor  storage.  Storage  will  not  be  considered 
because  tne  requirements  for  storage  are  not  adequately  addressed 
in  the  system  description.  storage  could  oe  viewed  as  tne  buffer 
storage  requirements  at  eacn  node  for  handling  many  messages.  It 
could  also  include  tne  processor  storage  for  tne  programs  wnicn 
must  perform  tne  message  processing  as  well  as  a  storage  manage¬ 
ment  scheme.  Since  not  enougn  data  is  available,  it  is  best  not 
to  waste  energy  by  including  this  in  tne  model.  Also,  tne 
requirements  for  buffer  storage  can  be  calculated  from  tne  queue¬ 
ing  statistics  of  tne  processors  and  channels. 

3.2.3  Definition  of  Objective 

Tne  objective  of  modelling  tne  communications  networx  is  to  pro¬ 
duce  quantifiable  results  for  the  system  design  for  all  perfor¬ 
mance  measures  stated  in  tne  system  description.  Tne  different 
Scenarios  and  designs  will  be  analyzed.  Results  will  be  tabu¬ 
lated  and  compared. 

Of  tne  various  configurations  described  in  section  3. 1.3.1  only 
the  seven  subnet  node  networx  topology  will  be  specifically 
addressed.  Tne  model  will  be  built  to  enable  rapid  reconfigura¬ 
tion  of  the  model  to  represent  all  three  conf ig ur a t ions .  Tnis 
will  be  done  by  maxing  the  logical  Processes  representing  message 
routing  independent  of  a  specific  architecture.  The  objective  of 
tnis  approacn  is  to  produce  a  general  submodel  for  modelling  mes¬ 
sage  communication  in  any  AI3IM  arcni tecture . 

3.3  Model  build 

3.3.1  Design ,  Plan  and  Construction  of  the  Mo-del 

3. 3. 1.1  Modal  Design  The  initial  model  design  consists  of  a 
structure  diagram  snowing  tne  operation  and  interfaces  of  tne 
model.  fne  sequence  of  events  which  initiate  activity  in  the 
model  are  described  in  this  structure. 
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Figure  V.  Example  1  Model  Structure 

3. 1.1. 2  Model  implementation  Plan  file  sequence  for  constructing 
tne  model  of  tne  communication  network  is  described  in  tne  fol¬ 
lowing  steps. 

1.  Oesiqn  and  Construct  model  for  message  routin-j. 

2.  Select  and  construct  model  of  subset  nodal  processing. 

3.  Define  subset  loading  Scenario. 

4.  Verify  message  routing  on  subset  of  network. 

3.  duild  complete  network  arcni tecture . 

6.  include  all  nodal  processing  functions. 

7.  Define  full  loading. 

3.  Define  full  Scenario. 
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9.  Verify  complete  networx  model. 

Id.  Analyze  results. 

3. 3.1.3  Model  Construction 

3. 3. 1.3.1  Messaq e  Routing  Creating  and  routing  messages  tnouqn 
an  architecture  is  tne  major  technical  feature  of  tae  system  to 
model  and  so  attention  is  first  directed  at  tne  loqic  for  tne 
Processes  wnicn  model  tnis.  me  initial  requirements  for  tnese 
Processes  are  derived  from  the  formulation  of  the  proolem  (sec¬ 
tion  3.2).  fne  requirements  are  described  below. 

1.  Messaqes  are  created  with  different  attributes  co r respond inq 
to  oriqin,  destination,  lenqtn,  requested  processing  and 
response  option. 

2.  A  Process  exists  in  every  node  wnicn  can  route  a  messaqe 
received  at  a  node  to  its  destination.  This  Process  can 
detect  from  tne  attributes  of  a  messaqe  received  at  tne  node 
wuetner  it  is  at  its  destination  of  not.  If  tne  messaqe  is 
at  its  destination,  the  processinq  requested  by  tne  messaqe 
is  initiated.  If  it  is  not,  a  Channel  transfer  is  initiated 
wnicn  forwards  tne  messaqe  to  its  destination. 

3.  Channel  transfers  interrupt  a  node  wnen  a  messaqe  nas  been 
transferred . 

4.  Wnen  a  messaqe  reacnes  its  destination  and  it  is  received 
and  processed,  a  response  is  initiated  if  one  is  requested. 

A  response  messaqe  returns  from  tne  destination  node  to  tne 
oriqin  of  tne  messaqe. 


In  order  to  meet  these  requirements  for  Processes,  it  is  neces¬ 
sary  to  come  up  with  a  data  and  Process  structure  for  tne  loqic. 


PROCESS 

ROUTER 


Figure  1U.  Massage  Routing  Structures 


Tne  Item,  MSG,  drives  tne  logic  of  tne  routing  processes.  "MSG" 
is  routed  tnrougn  an  Arcni feature  by  Processes.  Tne  Item  must 
contain  a  number  of  attributes  wnose  values  provide  tne  data 
wnicn  orients  tne  item  in  tne  Arcnitecture  at  all  instances  of 
simulated  time.  Embedded  in  tne  attributes  are  tne  values  for 
tne  source  node  of  tne  Item,  tne  destination  node  of  tne  Item, 
tne  current  node  of  tne  Item,  the  length  of  tne  communication 
message  in  bytes,  tne  name  of  the  reguested  process  to  be  ini¬ 
tiated  at  tne  destination  node  and  data  on  wnetner  tne  Process 
wnicn  initiated  tne  communication  is  waiting  for  a  response  or 
not . 

The  data  on  an  Item  "MSG"  is  used  by  tne  Processes  which  perform 
tne  message  routing  function.  A  Key  Process  will  be  called 
RJdffiR.  Tne  function  of  RJdrsa  is  to  determine  if  "MSG"  is  at 
its  destination  node  or  not.  If  "MSG"  is  at  its  destination 
node,  tne  node  responds  to  it  by  initiating  tne  Process 
reguested.  If  "MSG"  is  not  at  its  destination  node,  tne  next 
node  in  tne  Architecture  on  tne  patn  to  tne  destination  node  for 
"MSG"  is  determined  and  tne  Item  is  transmitted  to  it. 

Tne  seguence  of  tne  routing  Processes  is  then  developed.  For 
eacn  message,  a  similar  seguence  taxes  place.  dames  are  given  to 
tne  logical  functions  wnicn  correspond  to  each  Process.  RSQ-I/O 
is  tne  name  of  tne  process  wnicn  creates  tne  communication  mes¬ 
sage,  "MSG",  and  assigns  its  attributes.  "MSG"  is  passed  to  a 


Process  celled  ESR— CALL  wnicn  determines  if  taere  is  to  be  a 
response  associated  witn  tne  message.  If  taere  is  to  oe  a 
response,  tae  initiating  process  is  suspended.  If  taere  is  no 
response,  tne  initiating  Process  is  resumed.  Tne  next  Process, 
ROOFER,  determines  tne  next  node  in  tne  patn  to  tne  destination 
node  and  initatiates  a  cnannel  transfer  of  tne  message  to  tnat 
node.  CdLIO  represents  tne  queueing  time  for  tne  cnannel  and 
interrupts  tne  next  node.  IHANOLER  models  tne  interrupt  Handling 
logic  in  tne  next  node  and  continues  routing  tne  message  tnrougn 
tne  Arcnitecture  until  it  reacnes  its  destination  node.  Wnen  tne 
message  arrives  at  its  destination  node,  tne  requested  process  is 
initiated.  If  the  initiating  Process  wants  a  response,  a 
response  message  is  created  and  routed  back. 


REQ-I/O  INITIATES  A  CHAIN  OF  PROCESSES  UTILIZING 
CHANNELS  AND  NODES  ENROUTE 


Figure  11.  Message  Routing  process  Sequence 
3.3. 1.3. 2  Process:  REQ-I/O 

Process  REJ-I/O  is  tne  top  level  process  of  tne  Message  Routing 
Submodel.  mis  Process  causes  a  process  request  message  to  be 
generated.  Wnen  tnis  Process  is  called,  it  is  given  PROCESS, 
wnicn  is  tne  name  of  a  Process  to  be  initiated  in  tne  destination 
node  of  tne  message,  PRIORITY,  which  is  the  priority  wicn  wnicn 
PROCESS  is  to  be  initiated,  RESP.OPf,  wnicn  is  SWAIf  or  $NOWAir 
and  indicates  wnether  the  parent  will  wait  until  tne  initiated 
Process  completes,  MSG.LWrrf,  wnicn  is  tne  iengtn  in  bytes  of  the 
message,  TO. NODE,  wnicn  is  tne  destination  node  for  tne  message 
and  tne  node  in  wnich  PROCESS  is  to  be  initiated.  Tnis  process 
does  not  return  any  parameters. 


A  detailed  description  of  tne  parameters  of  tnis  Process  is  j  wen 
oelow . 

PROCESS  NAi4E :  RE  J-I/O  -  Generate  a  process  request  messaqe  on 
initiate  l7o. 

LOCATION:  executes  in  all  nodes. 

GIVEN:  PROCESS  (DATA  f*P£:  PROCESS)  -  Inis  parameter  is  tne  name 

of  tne  Process  to  Qe  initiated  in  tne  destination  node. 

PRIORI!*  (DATA  TYPE:  REAL)  -  Tnis  parameter  is  tne  prior¬ 
ity  wnicn  tne  initiated  process  is  to  nave  wnen  it  is 
s  tar  ted . 

RESP.OPT  (DAfA  rYPE :  ALPHA)  -  mis  parameter  is  tne 
option  for  tne  communication.  !ne  only  leqai  values  in 
tnis  parameter  are:  SWAII  -  tne  parent  process  will  wait 
until  tne  requested  Process  finisnes  before  it  resumes, 
SNOWAir  -  tne  parent  Process  does  not  wait  on  tne 
requested  Process. 

MSG.LNfH  ( DATA  rYPE:  REAL)  -  fnis  parameter  is  tne  lenqtn 
in  oytes  of  tne  communication  messaqe  routed  tnrojqn  tne 
network,  requestinq  tne  Process  to  be  invoked. 

TO. NODE  (DATA  TYPE:  RESOURCE  or  ALPHA)  -  Inis  parameter 
is  tne  destination  node  of  tne  messaqe  wnicn  is  tne  node 
in  wnicn  to  initiate  tne  requested  process.  If  tne  ALPHA 
variable  SYES  is  provided  for  tnis  parameter,  tne  node  of 
tne  requested  Process  is  computed  by  tne  $  NODE  Keyword. 

RETURN:  NONE 

CALLS:  ESR-CALL 


Followinq  is  tne  qrapnical  representation  of  Process  RE^-1/0. 
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OEND  «S£  FOR  SERVICE 


I  CALL 
I  EBR-CALL 

WAIT  19 


END  ' 


R3J-1/J  begins  by  creating  tne  message  and  initializing  various 
attribuces  of  it.  Tne  attributes  CNJl)3  and  FN0D3  are  tne  current 
node  in  wnicn  tnis  process  is  executing.  Tne  attribute  RTA3K  is 
set  to  tne  Process  wnicn  will  be  executed  in  tne  destination  node 
of  tne  message.  Tne  attribute  JSASKPRI  is  set  to  tne  priority 
witn  wnicn  tne  reguested  process  will  execute.  Tne  attribute 
R33PONS3  is  set  to  3WAIT  or  3NOWAIT;  x.e.  wnetner  tne  parenc  is 
to  wait  for  tne  reguested  Process  to  finisn  processing.  Tne 
attrioute  lengtn  is  set  to  tne  lengtn  in  bytes  of  tne  message. 
Next  tne  value  of  tne  destination  node  is  cnecxeu.  If  cne  value 
of  tne  destination  node  is  3/33,  then  tne  TNODE  a t tr ioote-- i . e . 
tne  destination  of  cne  message — is  set  to  oe  tne  node  in  wnicn 
tne  reguested  Process  executes.  otnerwise,  tne  name  of  tne 
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destination  node  is  supplied,  and  attribute  INODE  is  set  to  tiiis 
value.  Tnis  Process  tnen  calls  Process  ESR-CALn  and  gives  it  tue 
created  message. 

3 . 3 . 1 . 3 . 3  P  rocess :  ESR-CALL 

Process  ESR-CALL  is  called  by  REJ-1/0  and  eitner  suspends  tue 
requesting  Process  if  a  response  message  is  requested  (WAIT 
option)  or  allots  it  to  continue  processing  if  no  response  is 
requested  (NOWAIT  option).  Wnen  tnis  process  is  called,  it  is 
passed  tne  Item  MSG.  Tnis  Process  does  not  return  any 
parameters . 

PROCESS  NAME :  ESR-CALL  -  Executive  Service  Request  (CALL) 
LOCATION:  executes  in  all  nodes 

GI'/SN:  MSG  (DATA  TTPE :  ITEM)  -  Tnis  parameter  is  tne  communica¬ 

tion  messaqe  created  in  REJ-I/O  wnicn  contains  tne  data 
for  tne  Messaqe  Routing  Submodel. 

RETURN:  N/A 

CALLS:  ROUTER 


Following  is  tne  grapnical  representation  of  process  ESR-CALL. 


0PERBTIN6  SYSTEJ1:  EXECUTIVE  SERVICE  RE3UEST  (CALL  ) 
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CONTINUE  OR  RECUriE  POINT 


Tnis  Process  begins  by  setting  tne  message  attrioute  PTA3K  to  tne 
currently  executing  instance  of  tnis  process.  Tnis  value  is 
maintained  in  case  tnis  Process  is  suspended  and  is  to  be  resumed 
by  anotner  process.  Tnen  tne  response  option  of  tne  requesting 
process  for  tne  requested  option  is  retrieved.  Then  tne  Process 
calls  tne  Process  POUTER  to  begin  routing  tne  message  to  its  des¬ 
tination  and  waits  for  POUTER  to  complete.  Finally  a  test  is 
made  to  see  of  tne  previously  retrieved  request  option  is  $WAIT 
or  SN0WA1T.  If  it  is  $NOWAir,  ESP-CALL  completes.  If  it  is 
i?WAIT,  E3P-CALL  is  suspended,  naving  tne  effect  that  tne  request¬ 
ing  process  waits  until  tne  message  reacnes  its  destination,  tne 
requested  Process  executes,  and  a  response  is  routed  bacx  before 
tne  requesting  Process  finisnes  Processing. 

3. 3. 1.3. 4  Process :  POUTER 

Process  POUTER  determines  wnetner  tne  message  is  at  its  destina¬ 
tion  node.  Wnen  tnis  Process  is  called,  it  is  passed  the  mes¬ 
sage.  mis  Process  does  not  return  any  parameters. 


PROCESS  NArtE:  POUTER  -  Operating  System:  interrupt  Handling  and 
Routing 

LOCATION:  executes  in  all  nodes 

SI\/£N:  MSG  (DATA  T/PE:  I  TErt)  -  Tnis  parameter  is  tne  communica¬ 

tion  massage  created  in  PEJ-I/O  wnicn  concains  tne  data 
for  tne  logical  process  common icacion  protocol. 

RETURN:  NONE 
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CALLS:  CHLIO,  CONTROL 

Following  is  tne  jrapnical  representation  of  Process  RGJTOR 


OPERATING  SYSTEM  :  INTERUPT  HANDLING  AND  ROUTING 
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END  ) 


Tne  first  step  of  tnis  Process  is  to  assign  to  a  \zariaole  tne 
name  of  tne  node  wnich  is  tne  message's  current  position.  The 
message's  current  position  is  tnen  compared  witn  its  destination 
node.  If  at  this  point  tne  node  is  at  its  destination,  tne  des¬ 
tination  node  is  tne  same  node  whicn  generated  tne  message. 

Tnere  is  no  routing  overhead  delay  because  tne  message  did  not 
need  to  oe  routed  anywhere  (i.e.  rt.CS  is  zero).  file  process  tnen 
cescs  to  see  if  tne  message  is  a  request  messeqe  or  a  response 
message.  If  it  is  a  request  messaqe,  tne  routine  CONTROL  is 
called  witn  a  cJJWAir  option  and  a  priority  equal  to  tne  requested 
priority,  and  tne  requested  Process  is  initiated  in  tne  destina¬ 
tion  node.  If  tne  messaqe  is  a  response  messaqe,  tne  routine 
CdNIrtOL  is  called  witn  a  NJWAir  option  and  a  priority  of  zero, 
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and  tne  requesting  Process  is  resumed,  implying  that  tne  message 
nas  readied  its  destination,  tne  requested  process  nas  been  ini¬ 
tiated,  and  tne  message  nas  been  routed  Dacx  to  tne  node  froiP 
wnicn  it  was  generated. 

If  tne  node  is  not  at  its  destination,  tne  overhead  cost  for 
transfer  of  tne  message  from  its  current  node  to  its  next  node 
must  be  calculated.  Since  tnis  model  is  assuming  that  tne  over- 
nead  is  a  constant  value  because  tne  messages  are  all  tne  same 
length,  tne  mean  context  switching  time  (M.CS)  is  used;  tne  mes¬ 
sage  length  (MSG.LNTH)  and  tne  route  rate  per  length  (RT.OVHJ) 
are  not  used.  Tne  Action  ROUTE. OH  is  used  to  simulate  tnis  delay 
time.  Tne  routine  CHLIO  is  tlien  called  NOWAIT  to  forward  tne 
message  to  its  next  node,  and  the  Process  terminates. 

3 . 3 . 1 . 3 . 5  Process :  CONTROL 

Process  CONTROL  performs  two  different  functions  depending  on 
wnen  it  is  called.  Tnis  Process  is  passed  tne  message.  If  tne 
message  is  a  response  message,  then  at  tnis  point  tne  requesting 
Process  nas  waited  for  the  message  to  reach  its  destination,  tne 
requested  Process  to  be  initiated,  and  the  message  to  be  routed 
bacx.  At  tnis  point  the  message  nas  gone  full  circle  and 
returned  to  tne  requesting  Process's  node.  CONTROL  tnen  resumes 
tne  requesting  Process.  If  the  message  is  a  request  message, 
then  tne  message  is  at  its  destination  and  tne  requested  Process 
is  initiated  in  tnat  node.  If  the  requesting  process  is  waiting 
for  a  response,  tnen  the  attributes  of  tne  message  are  changed  so 
tnat  tne  original  source  node  is  now  the  destination  node,  and 
tne  message  type  is  changed  to  a  response  type.  Then  tne  routine 
CHLIO  is  called  to  route  the  message  back  to  the  requesting 
Process's  node.  If  tne  requesting  process  is  not  waiting  for  a 
response,  tne  message  is  destroyed. 

PROCESS  NAME:  CON TROL  -  Operating  Syscem:  Context  Switching 
LOCATION;  executes  in  all  nodes 

GIVEN;  MSG  (DATA  TTPE :  ITEM)  -  This  parameter  is  tne  communica¬ 
tion  message  created  in  REJ-I/O  wnicn  contains  tne  data 
for  tne  logical  process  communication. 

RETURN:  NONE 

CALLS:  CHLIO 

Following  is  tne  graphical  representation  of  tne  Process  CONTROL. 
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fne  first  step  is  to  allocate  tne  node  rftiere  the  message  is 
currently  located.  l'his  is  tne  node  wnere  tne  requested  process 
will  be  initiated  or  tne  node  in  wnicn  tne  requesting  process 
executes  (wnicn  is  currently  suspended).  fne  action  CS.Od  simu¬ 
lates  tne  delay  time  involved  in  the  context  swi toning.  Tne 
value  for  tnis  time  is  an  attribute  of  the  node.  i>Jext  tne  pro¬ 
cess  determines  if  tne  message  is  a  request  or  response  messaqe. 
If  ic.  is  a  response  messaqe,  tnis  Process  resumes  tne  suspended 
instance  of  tne  requestinq  process,  destroys  tne  messaqe,  deallo 
cates  tne  current  node,  and  terminates.  If  tne  messaqe  is  a 
request  messaqe,  tne  name  of  the  requested  process  is  retrieved 
from  tne  PfASK  attribute  of  tne  messaqe  and  the  Process  is  ini¬ 
tiated.  CJWI'tfdL  waits  until  tne  requested  process  completes. 


Next  CONTROL  cnee <s  tne  message  attribute  RESPONSE  co  see  if  tne 
requesting  Process  is  waiting  for  a  response.  If  a  response  is 
not  desired,  tne  message  is  destroyed  and  CONTROL  terminates.  If 
a  response  is  requested,  tne  message  type  is  changed  to  response, 
tne  destination  node  is  changed  to  tne  from  node  and  tne  from 
node  is  cnanged  to  tne  current  node.  Then  cne  Process  ROUTER  is 
called  to  route  tne  message  bacx  to  its  origin.  ROUTER  is  called 
witn  a  WAIT  option.  CONTROL  then  terminates. 

3. 3.1. 3. S  Process  :  CHLIO 

Process  CHLIO  determines  the  current  node  and  the  destination 
node  for  tne  message  wnicn  is  passed  to  it.  It  then  accesses  tne 
Legal  Patn  Tabic  to  determine  the  next  node  along  tne  route  and 
tne  cnannel  to  get  tnere.  The  cnannel  is  allocated  to  simulate 
its  use,  and  tne  routine  IHANDLER  is  called  to  interrupt  tne  next 
node . 


PROCESS  NAME :  CHLIO  -  full  and  naif  duplex  channel  logic 
LOCATION:  executes  in  all  nodes 

GI\/SN:  MSG  (OaTa  TfPE:  ITEM)  -  This  parameter  is  tne  communica¬ 

tion  message  created  in  REj-I/O  wnicn  contains  tne  data 
for  the  logical  process  commun ica t ion . 

RETURN:  NONE 

CALLS:  IHANDLER 

Following  is  the  grapnical  representation  of  the  Process  CHLIO. 


leil  "* 


FULL  AND  HALF  DUPLEX  CHANNEL  LOGIC 


/  START  \ 

\  CHLIO  / 


hcg  dnode 
assigned  to 
icnode 


:et  :st£?hcl  node  current 


;n:s  'node  j 

|  i:  assigned  to  j 

TO.  r»03E  | 


SET  DECT I SAT I ON  NODE  HISS) 


i*NXTHODE  *3. NODE 
ID  ASSIGNED  TO 
NXT  .NODE 


SET  next  node  TO  DEST  N 


'ichannel  to  ..node  i 
I  ID  ASSIGNED  TO  j 
CHANNEL  | 


SET  CHANNEL  TO  NEXT  NODE 


OBTAIN  CHANNEL  FOR  X  FER 


j  ALLOC 

\  CHANNEL 


CHANNEL  RATE 
IS  ASSIGNED  TO 
VSPEEB 


AHAT  IS  RATE  IN  3YTE/SEC'’ 


.NSC  LENGTH 
ID  ADS I ONES  TO 
VLEHSTH 


•"EDSAGE  LENGTH  IH  3YTES 


]VB.0VHB  MULTIPLY 
'SPEED 
'LENGTH 


CALCULATE  TRANDFER  TINE 


XFER.OH 


•VH.0VH8  I 


DELAY  DUE  TO  *»ANSFES  *I«E 


NXT.nODE 

I ^  A^I,NE3  TO  I 
HSC  CNODE 


NEDSAGE  RESIDES  IN  NEXT 


NXT.NODE 
IS  ASSIGNED  TO 
liCNODC 


DET  INTERNAL  NODE  REGISTER 


pd^e  42 


^  DEflLLOC 
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Tne  first  step  of  tnis  Process  is  to  assign  tne  current  node  of 
tne  message  to  $CNOD£  and  to  get  tne  destination  node  for  tne 
message.  Tnen  tne  next  node  and  linx  are  determined  based  on 
$CNOD£  and  tne  destination  node.  Then  tne  linx  is  allocated. 

Tne  transfer  time  for  tne  message  to  cross  tne  cnannel  is  alwa/s 
a  constant  rate  (tne  £\ZAL  calculation  using  tne  channel  rate  and 
tne  message  lengtn  is  ignored) .  The  Action  XFER.Od  simulates  tne 
time  used  to  traverse  tne  channel.  Then  the  current  node  attri¬ 
bute  of  tne  message  is  changed  to  the  next  node  to  update  tne 
message's  position,  and  tne  current  node  ($CNODE)  is  set  to  tne 
next  node.  Tne  linx  is  tnen  deallocated  and  tne  routine  IdANDLER 
is  called  to  interrupt  the  next  node  Processor. 

3. 3. 1.3. 7  Process:  IdANDLER 

Process  IdANDLER  is  similar  to  tne  Process  ROUTER.  IdANDLER  is 
passed  tne  message.  Tne  process  then  interrupts  a  processor  node 
by  allocating  tne  node.  If  the  message  is  not  at  its  destination 
node,  tnen  IdANDLER  computes  tne  next  node  in  tne  route  to  tne 
destination  node  and  calls  tne  routine  CdLIO  co  perform  tne  rout¬ 
ing.  If  tne  message  is  at  its  destination  node,  tnen  IdANDLER 
calls  CONTROL  to  initiate  the  reguested  Process  in  tne  destina¬ 
tion  node. 

PROCESS  NArtE :  IriANDLER  -  Operating  System:  interrupt  dandling  and 
Routing 

LOCATION:  executes  in  all  nodes 

GI7EN:  rtSG  (DATA  TtfPE :  ITEM)  -  Tnis  parameter  is  tne  communica¬ 

tion  message  created  in  REJ-I/O  wnicn  contains  the  data 
for  tne  logical  process  communication  protocol. 


HiSfLMW:  tfJNc: 


CALl-S  :  Crii_IJ,  CONTROL 

Following  io  tiie  jrapnieal  representation  of  Process  IJAWJL£R. 
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This  Process  first  determines  wnetner  tne  message  is  at  its  des¬ 
tination  node.  If  it  is,  IHANQL2R  calls  routine  CONTROL  to  ini¬ 
tiate  tne  requested  Process.  If  a  response  message  is  to  oe 
sent,  tnen  CONTROL  is  called  with  a  zero  priority;  otherwise,  it 
is  called  with  tne  priority  of  tne  requested  Process.  Either 
way,  CONTROL  is  called  with  a  NOWAIT  option.  If  tne  message  is 
not  at  its  destination,  tne  current  node  is  allocated.  Tne 
Action  ROUT  E . Ori  is  used  to  simulate  tne  delay  time  for  processing 
tne  routing.  Tnen  tne  node  is  deallocated  and  routine  CrfLIO  is 
called  NOWAIT  to  perform  tne  routing.  I HANDLER  tnen  completes. 

3.3. 1.4  Subset  of  Sys tern  A  single  tnread  Scenario  exercising 
tne  Message  Routing  Submodel  for  a  subset  of  tne  communication 
networx  is  used  to  verify  tne  logic  of  tne  suDmodel .  The  single 
tnread  Scenario  uses  three  nodes  and  models  a  hardcopy  request 
transmitted  from  airbase  61  to  the  command  headquarters  CHO 
tnrougn  subnet  switcn  processor  S7.  The  simple  architecture  is 
snown  oelow. 
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Figure  12.  Example  1  Subset  Architecture 

Tue  operation  of  tnis  test  case  initiates  with  a  Scenario  rESTl 
defined  in  tne  following  way.  TESfLOAO  initiates  tne  Process 
dCOPyCHJ  at  node  S7  at  the  start  of  tne  simulation.  This  is 
accompl isned  with  the  following  Scenario  and  Load  definitions. 
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SCENARIO  NAME:  TEST1  PERIOD  LENGTH ;  60U0U0 
DESCRIPTION ;  SINGLE  THREAD  TEST  CASE 
PERIODS :  1 

TRIGGER  SCH  TIME  PRIORITY 
TESTLOAD  U  0 


LOAD  NAME :  TESTLOAD 

NODE1 
S  7 

DESCRIPTION  : 

INITIATE  PROCESS  HCOPtfCHl 

PROCESS  MAX  t  SCH  MTD  MEAN  DELTA  PRIORI TT 
HCOPiTCHl  1  START  U 


Figure  13.  Example  1  Single  Thread  Test  Load  and  Scenario 
3. 3. 1.4.1  Process;  HCOP^CHj 

Tne  process  HCOPTCHO  represents  the  request  for  nardcopy  from  an 
airbase  to  tne  command  neadquar ters .  It  nas  tne  effect  of 
triggering  tnrouqn  a  CALL  to  REO-I/0  which  creates  a  message, 

MSG,  witn  LENGTH  attribute  equal  to  HCLNTH  (2UU  cnaracters) .  The 
TRACE  primitive  enables  tne  TRACE  output  whicn  tne  AI3IM  simula¬ 
tor  automatically  generates. 


Figure  14.  Process  HCOPfCHQ 
3. 3. 1.4. 2  Process:  CHJHD 

Tne  process  CHOHO  is  initiated  in  node  CH  after  tne  communication 
message  is  routed  tnrouqn  tne  network.  Hardcopy  qrapnic  response 
messages  are  63UU  characters.  The  Process  CHOHD  represents  tne 
reception  and  processing  of  nardcopy  requests  from  the  two  secon¬ 
dary  headquarters  HJl  and  HJ2.  It  is  initiated  by  tne  Processes 
HdlHGEN  and  HJ2HGEN  throuqn  a  CALL  to  HEJ-I/O.  Tne  Process  is 
qiven  a  reference  to  cne  Item  MSG  as  a  parameter.  Tne  first 
primitive,  ASSIGN,  sets  tne  value  of  tne  attribute  of  MSG  called 
HCHLNTri  to  tne  local  variable  MSG.LNFri  representinq  tne  lenqtn  of 
tne  nardcopy  data  messaqe.  In  tne  EVAL  primitive  tnat  follows, 
the  local  variable  M.OVriD  is  set  to  tne  product  of  MSG-LNTd  and 
CdJdOVriD,  wnicn  is  a  qlobal  variable  representinq  tne  overhead 
for  nardcopy  requests  in  bytes/second .  The  variable  M.O\MD  is 
tnus  equal  to  tne  time  overhead  of  the  response  to  tne  nardcopy 
request  from  djl  and  HJ2.  An  appropriate  amount  of  time  is  tnen 
taken  up  in  an  ACTION  primitive  and  tne  Process  tnen  returns  the 
reference  to  tne  Item  MSG  to  tne  cailinq  process.  The  qrapnic 
representation  of  CHJHO  is  snown  in  Fiqure  15. 
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Figure  15.  Process  Cd^HD 
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Figure  16.  Example  1  Single  Thread  Trace 
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3.  J.l.  5  Complete  Networx  a  r  c  n  i  t  e  c  t  u  r  e  file  specif  l  canon 
requires  a  system  of  many  airbases,  two  neaciquar  ters ,  a  singie 
command  headquarters  and  swi tcnes  to  route  messages  between  any 
of  tne  other  physical  elements  in  tne  system,  A  number  of  archi¬ 
tectural  topologies  would  accommodate  tnis  description.  fne  pur 
pose  of  tne  model  is  to  test  switching  capacity.  5 ta t is t i cal 1 y 
speaxing,  eacn  of  tne  airbases  imposes  tne  same  load  on  tne  sys¬ 
tem.  A  simpl if ication  to  replace  tne  collection  cf  kinases 
around  eacn  swi ten  by  a  single  airbase,  compensating  for  tne 
reduced  number  by  increasing  tne  load  from  tne  sinqle  base  by  an 
appropriate  factor,  can  be  done.  Adapting  tne  7  subnet  arcmtec 
ture  by  tnis  simplification  produces  an  architecture  for  tne  sys 
tern  snown  in  Figure  17. 
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Figure  17.  Tne  Complete  Network  Architecture 
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tne  six  nodes  labeled  "a"  represent  airoases;  tne  nodes 
led  "ri"  are  headquarters  and  the  node  "Cd3"  represents  a  com- 
neadquar ters;  tne  squares  laoled  "S"  are  tne  switches 
uqn  wnicn  any  messages  between  airoases,  headquarters  or  com- 
neadquarters  must  be  routed.  The  Legal  Path  Table  is  in  tne 
determined  by  the  topology  of  tne  networx  itself,  in  con- 
tion  wi tn  tne  routine  tables  (figure  4).  Leaf-nodes 
esenting  airoases,  headquarters  and  command  headquarters  corn- 
cate  with  any  other  nodes  in  tne  system  tnrougn  its  contigu- 
switen.  Tne  archi tecture ,  througn  tne  presence  of  tne  tne 
between  tne  swi tones  S4  and  S7  (together  with  tne  question 
ireccion)  ,  allows  for  several  alternative  patiis  between 
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switcnes,  amongst  wnicn  the  user  must  cnoose  explicitly. 


3. 3. 1.6  Node  P rocess  Def ini tions  In  order  to  represenc  node 
processing  functions,  twenty-two  distinct  Processes  representing 
tne  various  operations  of  tne  communication  system  nad  to  be 
defined.  figure  13  contains  a  taQle  showing  tne  system  of 
processes  in  tne  model.  fhe  left  nand  column  indicates  tne  name 
of  eacn  Process  as  it  appears  in  the  model.  The  miadle  column 
indicates  wnicn  of  the  tnree  activities  modeled  in  tne  Process 
are  represented  by  tne  named  Process  and  the  tnird  column  shows 
tne  Process  tnat  is  triggered  by  the  one  named  to  the  left  and 
wnat  activity  it  represents.  The  AISIM  representation  of  eacn  of 
tne  Processes  is  described  with  _  rationale  for  its  design. 
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B-ORICIN  -  stub  process 

HQ2DCEN 

Data:  HQ2  to  HQ1 

HQ  -  Process  data  message 

Data:  RQ2  to  CHQ 

HQ  -  Process  data  aessage 

HQ2CCCT 

Graphics  request:  HQ2  to  CHQ 

C11QGT)  -  Process  graphics  request 
message  and  send  response  to  origin 

HQ2HOEN 

Hardcopy  request:  HQ2  to  CHQ 

CHQHD  -  Process  hardcopy  request 

message  and  send  response  to  origin 


Figure  13.  Example  1  Processes 

3. 3. 1.6.1  Processes  DATAddOl  through  PATAB607  The  seven 
Processes  DAfAddOl  througn  DATAdd07  represent  tne  transmitting  of 
data  messages  from  one  airbase  to  another.  Each  of  the  Processes 
consists  of  a  simple  call  to  REJ-I/O  which  initiates  an  instance 
of  tne  Process  dSCHO  (discussed  below) .  dECHO  generates  and 
transmits  a  return  message.  Eacn  of  these  seven  processes 
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differs  in  out  one  parameter,  namely,  tne  node  to  wnicn  cue  data 
is  transmitted.  Below  is  tne  grapnic  r epresentation  of  JATABBOl: 
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RETURN 
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Figure  13.  Process  DATABBU 1 

fne  annotations  at  tine  left  of  tne  START  figure  indicate,  first, 
that  tne  Process  executes  in  all  nodes — though,  in  fact,  its  exe¬ 
cution  will  be  confined  to  "B"  nodes.  Secondly,  tne  Process  has 
no  attacned  attributes.  Fne  parameters  to  the  left  of  tne  CALL 
primitive  carry  tne  values  accessed  by  tne  Message  Routing  Submo¬ 
del,  of  wnich  “RE^-I/O"  is  tne  top-level  Process. 

3. 3. 1.6. 2  process :  BSCHO  Tne  Process  BSCHO  ecnos  a  message  bacx 
to  tne  node  from  wnicn  it  wa s  triggered.  It  does  tnis  by 
triggering  tne  stub  process  B-DRIGIN  througn  tne  Message  Routing 
Submodel,  .vnicn  is  initiated  by  RSJ-I/O.  Tne  grapnic  representa¬ 
tion  of  BECHJ  is  snown  in  Figure  20. 
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Figure  20.  Process  BECHJ 
i.J.1.6.3  Process:  d-ORIGIN 

Tne  Process  B-ORIGIN,  which  is  triggered  by  H^lDGEN  and  dJ2DGErt 
(discussed  below)  ,  consists  merely  of  a  START  symbol  and  an  ErJD 
symbol.  Its  purpose  is  to  allow  tne  computation  of  o«/eraead 
accrued  in  tne  transmission  of  messages  from  tne  two  secondary 
headquarters  (ri-Jl  and  BJ2)  to  tne  airbases  (tne  S  nodes).  Tne 
qrapnic  picture  of  B-ORIGIN  is  shown  in  Figure  21. 


Paq  a  5  5 


3: 


1  THIS  IS  fl  3-NODE  STUB  °R0CE2S 

1  HSC  CIVEM  fm W)  HSC 

V  3— SRISIH  j 


RETURN 


ALL 

NO 


33 


'34j 


,35 


96 


32 


(  END 


Figure  21.  Process  s-ORICilN 

3. 3. 1.7  Processes:  DATAdCHd,  OATAStiJl  and  DATABB32  The 
Processes  DATABCrfd,  DA TABBdl  and  DATABB32  all  represent  tne  send¬ 
ing  of  messages  from  airbases  to,  respectively,  tne  command  head¬ 
quarters  (CHJ)  and  the  two  subsidiary  headquarters  BJ1  and  B32. 
fiacn  of  tnese  processes  is  triggered  in  all  of  tne  B  nodes.  The 
effect  of  tnese  three  Processes  is  to  triqqer  the  Process  Bd  in 
eacn  of  tne  three  destinations,  which  is  done  by  callinq  the  pro¬ 
cess  Bd  in  the  CBd,  HJl  and  Hd2.  Thus,  these  three  Processes 
differ  only  in  the  destination  node  that  given  as  a  parameter  in 
tne  CALL  to  BtSd-I/O — the  top-level  Process  in  tne  Message  Rout¬ 
ing  dubmodel — of  tne  Process  aj.  The  process  B2  (discussed 
below)  represents  tne  reception  and  processing  of  a  message  in 
tne  destination.  Tne  flow-chart  representation  of  DATABCBd  is 
Shown  in  Figure  22;  tnat  of  DATAdBdl  in  Figure  23  and  that  of 
DATA B J  in  Figure  24. 
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Figure  24.  Process  DATAHJ2 

3. 3. 1.7.1  Processes:  HJ1DGEN  and  dQ2PGEN  The  Processes  djlDGEN 
and  HJ2DGEN  represent  the  generation  and  transmission  of  a  mes¬ 
sage  at  tne  HJl  and  rij2  nodes.  The  generated  messages  are  con¬ 
ceived  to  be  sent  to  airbases,  the  command  headquarters  and  tne 
opposite  secondary  neadquar ters .  Therefore,  HJ1DGEN  and  8Q2DGEN 
eacn  initiate  tnree  Processes:  the  Process  HQ  is  triggered  in  tne 
opposite  headquarters  (riQl  or  UQ2)  node  and  in  tne  Cd2  node.  The 
Process  8-ORIGIN,  discussed  above,  is  triggered  in  83.  These 
tnree  initiations  are  effected  througn  calls  to  REQ-I/O.  The 
grapnic  version  of  ajlDGEN — «vnich  is  identical  to  H02OGEN  except 
in  locus  of  execution  and  in  tne  destination  of  its  messages — is 
given  in  Figure  25. 
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Figure  25.  process  rijlDGEN 

3. 3. 1.7. 2  Processes  :  dJIGGEN  and  dsj2GG£N  Tne  processes  djlGGEN 
anc  d J2GGEN  represent  the  transmission  of  a  graphics  request  from 
eacn  of  tne  two  secondary  neadquarters  to  tne  command  head¬ 
quarters.  fnese  Processes  both  na^e  tne  affect  of  initiating  a 
Process  in  tne  CdJ  node,  namely  CdJG2>,  to  represent  tne  reception 
and  processing  of  tne  graphics  request.  dQlGGEd  is  represented 
in  f low-cnar  t  form  in  Figure  26.  dJlGGEd  and  d J2GGEN  are  identi¬ 
cal  except  for  tne  tne  nodes  in  wni cn  they  execute. 
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Figure  26.  Process  HQ13GEN 
3. 3. 1.3  Processes:  HJlriGEN  and  Hj2H3EN 

Tne  Processes  rijlHGEN  and  i3J2HGEN  represent  tne  generation  of  a 
request  for  nardcopy  from  tne  secondary  headquarters  to  tne  com¬ 
mand  neadquarters.  They  are  triggered  in  the  nodes  HQ1  and  ri,}2 
and  in  turn  call  a  Process  CHJriD  in  tne  CHJ  node.  H31H5EN  is 
identical  to  HQ2HGEN  except  in  node  of  execution. 
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Figure  27.  Process  HOldGEN 

J.i.1.9  Process ;  CilQGQ  The  Process  CHOGO  is  muen  lixa  CdJriD. 

It  represents  tne  processing  of  a  grapnics  reguest  from  the  two 
secondary  neadguar ters .  It  is  called  by  tne  Processes  H^IGGEN 
and  HJ2G3EN.  In  it,  a  reference  to  tne  Item  riSG  is  passed  from 
tne  calling  process.  An  attribute  of  riSG  is  accessed  by  tne 
ASSIGN  primitive  and  its  value  is  assigned  to  a  local  variaole. 
Tnat  value  is  tnen  used  to  evaluate  (v/itn  tne  E7AL  primitive)  tne 
overhead  time  entailed  in  tne  response  to  tne  reguest.  An  ACTION 
primitive  tnen  ta<es  up  tne  calculated  amount  of  time  and  the 
reference  to  rtSG  is  returned  to  tne  calling  Process.  Tne  flow- 
cnart  rendering  of  CriJGD  is  snown  in  Figure  28. 
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Figure  28.  Process  CdjGD 

3.3.2  Load ;  LOAOSOl  Load  LOADSQ1  describes  the  Load  placed  on 
tne  communication  system  from  hosts  connected  to  SOI.  Remember¬ 
ing  the  assumption  made  tnat  all  hosts  connected  to  a  switcn  node 
can  be  represented  oy  one  node  witn  the  channel  transfer  con¬ 
straint  relaxed,  LOADSOl  specifies  the  Processes  wnich  initiate 
at  node  801. 

There  are  two  types  of  messages  wnich  originate  at  SI,  data 
request  messages  with  a  mean  message  length  of  750  characters, 
and  nardcopy  display  request  messages  with  a  mean  message  lengtn 
of  200  characters.  Display  request  messages  from  node  BOl 
request  data  be  sent  to  node  Hdl,  the  Crfd  node  and  echoed  Dacx  to 
Bl. 

In  order  to  specify  tne  Load  to  AISIM,  tne  messages  rates  gi/en 
in  Figures  7  and  3  in  msg/sec,  poisson  distriouted  need  to  be 
expressed  by  an  interarrival  rate  given  in  sec/msg .  fnu  exponen¬ 
tial  distribution  represents  a  poisson  arrival  pattern  for 
interarrival  times. 

Tne  computation  of  mean  interarrival  rate  for  message  generation 
at  node  BOi  is  computed  in  the  following  way.  Data  messages  nave 
a  message  race  of  .517  msg/sec  (Figure  7  —  Message  Traffic 
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Lnarac ter  is t ics)  .  fills  is  distributed  94£  to  all  3  nodes  (Figure 

7  —  Message  Traffic  Sources) .  That  is,  tne  message  rate  for  tne 
system  originating  at  3  nodes  is  .517  msg/sec  x  .94  =  .436 
msj/sec.  Distributing  this  to  seven  nodes  equally  .neans  tnat  any 
one  S  node  nost  has  a  message  generation  rate  of  (.  466  msg/sec) /7 
S-nodes  =  .07  msg/sec  per  S  node  nost.  Inverting  tnis  for 
interarrival  time  gives  14.4039  secs/msg  per  3  node  nost.  Tnis 
is  tne  interarrival  rate  for  data  request  Process  triggering 
wnica  applies  to  Processes  DATABB01,  DATABCHQ,  and  DAPAdrijl  which 
oriqinate  at  source  node  dOl  (Fiqure  3).  Tne  computation  for 
Hardcopy  display  request  qeneration  from  nod2  dOl  uses  a  similar 
method  to  compute  tne  mean  interarrival  time  for  HCOP/CHQ 
processes  originating  at  301.  Tne  time  for  this  is  14.643 
sec/msq  . 


The  definition  of  LGADS01  is  snown  in  tne  followinq  fiqure. 

Loads  oriqinatinq  at  otner  nodes  d02  tnrouqn  d07,  HQ1  and  HQ2, 
are  calculated  in  a  similar  manner  from  the  data  in  Figures  7  and 
3. 
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Figure  29.  Example  1  Load  Originating  at  Node  SOI 
3.4  Analysis  of  Results 


3.4.1  Performance  Measures  Eacn  node  and  channel  on  the  AISIM 
architecture  represents  a  resource  in  tne  system.  The  statistics 
for  tne  performance  of  tne  resources  described  in  section  3.1.1 
are  found  in  the  AISIM  Resource  Report. 


3. 4. 1.1  Communications 
by  one  or  two  resources 
or  full  duplex.  Commun 
RESOURCE  WAIT  TIME.  Tn 
ures  refer  to  the  mean 
mean,  minimum  wait  time 
These  figures  are  based 
of  samples  collected  fo 
tne  wait  time  of  a  mess 
given  for  eacn  channel. 


Queue  T ime  Each  cnannel  is  represented 
depending  on  wnetner  tne  channel  is  naif 
ications  queue  time  is  expressed  as  tne 
e  MEAN,  STD  DEtf,  MINIMUM  and  MAXIMUM  fig- 
wait  time,  standard  deviation  about  tne 
and  maximum  wait  time  for  messages, 
on  the  TOTAL  NUMBER  wnich  is  the  numoer 
r  the  statistic.  Eacn  sample  represents 
age  for  tne  cnannel.  These  values  are 
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A  " collec ti ve"  statistic  for  commun ica t ion  queue  time  can  be 
found  in  tne  Process  Report  under  RESOURCE  WAI f  for  tne  process 
CriLIO .  Tnis  neadinq  lists  tne  SUM,  MEAN ,  STANDARD  DEVIATION, 
MINIMUM  and  MAXIMUM  wa  i  t  times  accumulated  for  tne  Process  wait¬ 
ing  on  tne  ALLOC  Primitive.  Eacn  instance  of  CriLIO  corresponds 
to  a  separate  instance  of  a  message.  Since  tnere  is  only  one 
ALLOC  Primitive,  tne  RESOURCE  WAIT  statistic  collects  tne  time 
for  all  messages  in  CriLIO. 

3. 4. 1.2  Communication  Channel  Queue  Lang th  Tne  cnannel  queue 
lenqtn  statistics  are  found  in  tne  Resource  Report  for  eacn  cnan¬ 
nel  in  tne  arcni tecture .  The  statistic  is  listed  under  tne  4 
WAITING  neadinq,  wnich  is  tne  collection  of  samples  fatten  by  tne 
AI3IM  simulator  eacn  time  the  Resource  wait  queue  is  chanqed. 

Tne  J  WAITING  statistics  are  time  weighted,  whicn  means  that  tne 
MEAN  4  WAITING  statistic  taxes  into  account  how  long  tne  Resource 
wait  queue  was  a  given  length. 

3. 4. 1.3  Processor  Queue  T ime  Tne  queue  time  for  processors  is 
snown  in  tne  AISIM  Resource  Report  for  each  processor  node  iden¬ 
tified  on  tne  system  architecture.  As  for  cnannels,  processor 
queue  time  is  listed  as  the  Resource  Wait  Time  in  the  report. 

3. 4. 1.4  Processor  Queue  Leng  tn  The  queue  lengtn  for  processors 
is  snown  in  tne  AISIM  Resource  Report  for  each  processor  node 
identified  on  tne  system  arcnitecture .  as  for  channels,  proces¬ 
sor  queue  lengtn  is  listed  as  the  Resource  ^  WAITING  in  the 
report. 

3. 4. 1.5  Communications  Channel  Util ization  The  communication 
cnannel  utilization  for  each  channel  in  tne  architecture  is 
listed  in  tne  Resource  Report  under  tne  t  dUSf  neadinq.  The  MEAN 
J  dUStf  statistic  gives  tne  percent  utilization  of  the  channel. 

Tne  MEAN  i  dUSZ  is  a  time  weiqnted  statistic  which  is  updated  by 
tne  AISIM  simulator  each  time  a  channel  is  made  idle  by  a  DEALLJC 
Primitive.  The  time  tne  cnannel  was  busy  is  added  to  tne  total 
busy  time.  At  tne  end  of  tne  simulation  tnis  is  divided  by  tne 
total  simulation  clock  time. 

3. 4. 1.6  Processor  Util ization  Tne  processor  utiliazation  for 
eacn  processor  in  "tne  arcni tecture  is  listed  in  tne  Resource 
Report  under  tne  i  dUST  neading.  Tne  MEAN  &  dUS/  statistic  gives 
tne  percent  utilization  of  tne  cnannel.  Tnis  statistic  is  time 
weighted,  wnicn  is  updated  by  tne  AISIM  simulator  eacn  time  a 
processor  is  made  idle  by  a  DEALLDC  Primitive.  The  time  tne  pro¬ 
cessor  was  busy  is  added  to  the  total  busy  time.  At  tne  end  of 
tne  simulation  tnis  is  divided  by  tne  total  simulation  clock 
time . 

3. 4. 1.7  0 ther  Performance  Measures  dased  on  tne  way  tne  model 
nas  been  built,  it  is  not  possible  to  get  message  response  times 
by  source  and  destination  nodes.  For  tnose  processes  wnich  call 
REQ-I/D  with  tne  WAIT  option,  message  response  time  can  be 


obtained  oy  ranction  from  tne  output  listing  under  tr.c  Process 
Report.  fa  1  s  appears  under  the  fOfAL  Heading.  mis  teadinj 
lists  tne  TOTAL  SAMPLES,  SUM,  MEAN  ,  STANDARD  DE  71 A  TI ON  ,  MINIMUM 
and  MAXIMUM  completion  times  of  tne  process.  For  Processes  HARD¬ 
COPY  ,  HCOPYCHO ,  HQIGGEN ,  HOlSGEN,  H02GoEN  and  R02HuEN,  tae 
response  time  is  accumulated  under  tnis  statistic. 
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Validating  tne  Model  Tne  node  and  channel  utilizations 
11  resources  in  tne  architecture  can  be  calculated  analyti- 
.  Utilization  is  a  function  of  tne  Load  (message  generation 
and  tae  processing  times.  For  channels,  tne  processing 
is  dependent  on  message  lengths  and  channels  transmission 
s.  For  processors,  tne  processing  time  is  dependent  on  mes- 
lengtns  and  processor  cycle  speeds.  These  figures  are 
able  and  can  be  calculated.  Comparing  expected  utilization 
sources  to  simulation  generated  results  provides  a  first 
of  validity. 
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Figure  30.  Example  1  Node  Utilization  Results 
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Channel  Utilization  (in  s ) 
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Figure  31.  Example  1  Channel  Utilization  Results 
3.5  Conclusions 

Tile  AlSIrt  model  of  the  communication  networx  is  very  representa¬ 
tive  of  the  system  description.  The  approach  taxen  for  this 
model  demonstrates  a  tecnnique  wnicn  can  be  used  very  success¬ 
fully  in  simulation  modelling.  That  is,  building  a  general  sub¬ 
model  to  represent  a  specific  function  in  the  system.  The  advan¬ 
tage  of  eliminating  dependence  of  model  components  is  that  tae 
fewer  dependencies  in  a  model,  the  more  easily  adapted  it  is  to 
otner  applications. 

Example  1  is  certainly  not  a  simple  problem.  For  that  reason  the 
solution  approach  shown  is  not  trivial.  Still,  tne  model  imple¬ 
mentation  plan  consists  of  a  manageable  set  of  discrete  steps 
towards  model  implementation. 


4. 


example  2 


Loop  Communication  Network 


Example  2  demonstrates  tne  application  of  AISIM  to  anocaer  com¬ 
munication  system  utilizing  a  loop  protocol.  Unlike  example  1 
wnere  low  level  protocols  of  tne  subnet  node  communication  was 
not  described,  modelling  a  loop  involves  addressing  some  basic 
elements  of  cne  communications ,  like  buffers  and  slots. 

A  loop  is  described  most  basically  as  single  direction,  circular 
communication.  mis  example  concentrates  on  a  loop  system  usinq 
a  Pierce  protocol. 

fnis  example  snows  now  it  is  possible  to  use  parts  of  previously 
developed  models  to  quickly  qenerate  a  new  model  of  a  totally 
different  system. 

4 . 1  Input 

4.1.1  Mission  Concept  Nodes  in  a  network  communicate  tnrouqn  a 
Pierce  loop  areni tecture .  A  Pierce  loop  is  described  by  a  circu¬ 
lar  linked  areni tecture .  Messages  communicate  between  nodes  by 
circulatinq  around  cne  arcnitecture  via  message  slots.  The  nodes 
are  tne  "users"  of  tne  communication  loop.  £acn  node  represents 
a  processor  servicing  its  own  class  of  users.  Processinq  and 
data  is  distributed  to  tne  nodes,  necessi ta tinq  tne  incer-node 
communication . 

4.1.2  problem  Perspective  Several  messaqes  may  be  in  tne  net¬ 
work  simul taneously .  fne  performance  of  tne  communica cion  system 
usinq  a  varyinq  mix  of  messaqes  will  indicate  whether  messaqes 
are  efficiently  nandled.  Tne  followinq  are  definitions  of  per¬ 
formance  criteria  for  this  example. 

1.  jueueinq  Time  -  Time  elapsed  from  messaqe  qeneration  until 
start  of  placement  on  tne  loop  by  tne  transmitter. 

2.  Transmission  rime  -  Time  elapsed  from  tne  start  of  messaqe 
placement  on  tne  loop  until  it  is  received  at  its  destina¬ 
tion  and  removed  from  tne  loop. 

J.  Total  Messaqe  Transmission  Time  -  Sum  of  queueinq  and 
transmission  times. 

4.1.3  System  Description  Tne  followinq  character istics  apply  to 
tiie  network: 

1.  The  network  consists  of  six  nodes. 

2.  Messaqes  are  qenerated  randomly  at  eacn  node  and  uniformly 
addressed  to  the  other  five  nodes. 

3.  A  messaqe  consists  of  1  packet.  Each  packet  consists  of  36 
characters . 
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In  the  Pierce  loop,  fixed  lengtn  slots  "circulate"  around 
tne  loop.  A  lead  field  of  tne  slot  indicates  whecner  or  not 
tne  following  frame  is  occupied.  In  tne  absence  of  a  mes¬ 
sage,  a  dost  may  insert  a  message  (or  portion  thereof)  into 
tne  availaole  slot. 


E:  Empty 
0:  Occupied 


Fiyure  32.  Pierce  Loop  Diagram 
4 . 2  Preliminary  Analysis 

aISIM  is  applicable  to  tnis  problem.  Message  communication  in  a 
loop  network  can  be  described  by  discrete  events.  The  discrete 
events  of  interest  in  the  loop  communication  are  tne  following: 

1.  Message  created  at  a  node. 

2.  Message  queued  at  origin  for  slot. 

3.  Start  slot  transmission  on  loop. 

4.  Slot  received  at  loop  interface  unit. 

3.  Slot  routed  to  next  loop  interface  unit. 

6.  Message  received  at  destination,  processed  and  eliminated. 
Eacn  of  tnese  events  can  be  modeled  by  procedural  operations. 
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Man/  slots  circulate  on  tne  loop  simul taneousi/.  Blocs  are  pro¬ 
cessed  in  parallel  at  nodes. 

Resources  in  tne  system  consist  of  node  processors,  node  storage 
buffers,  and  channel  connectors  between  nodes. 

Tne  incidence  of  messages  introduced  into  the  system  descrioes 
tne  external  loading. 

A  loop  is  a  subset  of  an  interconnected  network  arcax tec ture . 

Eacn  node  nas  exactly  2  connectors,  eacn  to  adjacent  nodes  in  tne 
architecture.  Communication  is  implemented  in  only  one  direc¬ 
tion  . 

4.2.1  Proolem  Definition  The  elements  to  be  analyzed  in  tne 
loop  communication  system  can  be  grouped  into  two  categories. 

fne  first  addresses  unidirectional  message  communication  from  any 
source  node  to  any  destination  node  around  tne  loop  tnrougn  tne 
loop  interfaces.  Here  the  model  will  represent  random 
occurrences  of  messages  in  tne  system  at  source  nodes,  to  be  sent 
arbitrarily  to  nodes  in  the  loop.  This  nign  level  approacn  will 
generate  tnroughput  statistics  on  messages  based  on  tne  inter¬ 
arrival  rates  of  messages.  processing  and  queueing  for  proces¬ 
sors  and  cnannels  will  be  represented. 

The  lower  elements  of  this  system  —  slot  synchronization ,  slot 
processing,  and  message  buffering  will  be  represented  in  tne 
extended  model. 

Although  basic  to  loop  communications,  varying  message  lengths 
will  not  be  addressed.  It  is  assumed  that  the  Loads  representing 
the  external  environment  of  the  system  taxe  into  account  the 
software  which  assembles  and  disassembles  messages. 

4.2.2  Def ini tion  of  objective 

fne  objective  of  modelling  the  loop  communication  network  is  to 
produce  quantifiable  results  for  the  performance  measures  in  tne 
system  description.  The  model  will  be  built  first  to  satisfy  tne 
high  level  elements  of  tne  system  described  in  tne  proolem  defin¬ 
ition  (unidirectional  loop  architecture,  random  message  load) . 

The  model  will  be  extended  to  include  tne  lower  level  elements 
(slots  and  message  buffering)  . 

4.3  Model  Build 


4.3.1  Design ,  Plan  and  Construction  of  the  Model 

4. 3. 1.1  Model  Design  A  two-step  approach  is  used  to  design  the 
model  cased  on  the  two  categories  of  modeling  problems  identified 
in  tne  problem  definition.  fne  preliminary  design  maxes  use  of 
tne  message  routing  submodel  described  in  Example  1.  Tne  choice 
of  this  submodel  at  tnis  time  is  based  on  experience  tnat  it  is 
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easier  to  start  from  some  Known  model  than  it  is  to  start  from 
scratch  if  it  Iooks  liKe  the  elements  addressed  are  similar 
enough.  Unidirectional  flow  and  random  origin  ana  destination 
nodes  fit  tne  message  routing  submodel  assumptions. 


!  SCENARIO  I 


triggers 


I  LOAD  I  Select  source  node 


triggers 

I 


I  GEN-MSG  |  Select  destination 

- node 

I 

calls 

! 

-  route  message 

I  RED-I/O  |  from  source  to 
-  destination 

4. 3. 1.2  Model  Implementation  Plan  The  sequence  for  constructing 
tne  model  of  the  Pierce  loop  communication  network  is  described 
below: 

1.  Define  Pierce  loop  architecture. 

2.  Interface  message  routing  submodel  (from  Example  1)  to  loop 
model . 

3.  Build  generation  Process(es). 

4.  Verify  message  routing  submodel  on  loop  arcnitecture. 

5.  Define  system  parameters  and  full  loading. 

6.  Analyze  nigh  level  loop  model. 

7.  Design  lower  level  elements  into  model  (slots  and  buffers) . 
3.  Build  models  of  lower  level  elements. 

g.  Verify  new  network  model. 


10.  Analyze  results. 
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4  •  3 . 2  Define  Pierce  Loop  A  r  c  a  i  tecta  re  Defining  tae  Pierce  loop 
architecture  for  a  six  nost  networx  is  a  straightforward  tasx. 
£acn  nose  and  loop  interface  unit  can  oe  represented  oy  a  node, 
fa  is  assumes  tnat  loop  interface  units  are  embedded  in  nosts  and 
not  a  separate  hardware  element  wnich  needs  to  oe  addressed  as  a 
neeworx  element.  Tais  is  reasonable  based  on  tne  information  in 
tae  system  description.  £aca  node  nas  two  linxs  representing 
communications  caannels  to  adjacent  nodes,  Tae  leaa.l  path  taole 
for  tnis  network  describes  tae  directional  flow  of  messages. 
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Figure  34.  Example  2  Legal  Path  fable 


4.3.3  Interfacing  Message  Routing  Submode  to  Loop 
Model  including  the  message  routing  submodel  in  the  loop  model 
is  done  by  merging  the  entities  developed  in  Example  1  for  mes¬ 
sage  routing,  tne  Item  MSG,  tne  six  Processes,  the  Actions,  and 
global  Variaoles,  into  a  loop  model.  Tnis  is  done  witn  the  AISIM 
Library  User  Interface.  The  message  routing  submodel  is  inter¬ 
faced  to  tne  loop  model  by  defining  the  Resources  to  have  the 
attributes  addressed  in  tne  Processes  and  defining  tne  processes 
which  invoxe  REJ-I/O. 


4.3.4  Process :  GEN -MSG  A  Process  which  controls  tne  generation 
of  messages  determines  source  and  destination  nodes  for  eacn  mes¬ 
sage  and  indicates  a  Process  to  be  initiated  at  tne  destination 
node  to  nandle  tne  message.  Processes  can  be  oriented  in  a  net- 
worx  tnrougn  tne  NODE  fields  of  a  Load  entity.  This  is  a  natural 
mechanism  for  determining  source  nodes  for  messages.  me  source 
node  is  tne  node  which  executes  the  message  generation  process. 


There  are  many  strategies  wnich  can  be  considered  for  tne  logic 
to  determine  destination  nodes  for  messages  generated  at  a  source 
node.  For  economy  in  effort,  a  good  approach  would  be  to  define 
a  single  process  which  would  execute  in  all  nodes  and  distribute 
messages  to  all  otner  nodes  uniformly,  mis  can  De  done  by  defin¬ 
ing  an  AISIM  fable,  indexed  by  a  random  inceger,  wnicn  evaluates 
to  tne  name  of  a  node  in  the  Architecture.  Tne  definition  of 
this  Table  is  snown  below: 


TABLE  NAME ;  NODE-TBL  TTPE :  A 

DE3CBIP  TION ;  TABLE  WITH  NAME  OF  EACd  NODE  TO  BE  ACCESSED 
HANDOi'lLf 


X-^ALUE 

0 

1 

2 

3 

4 

5 


T-TALJE 

B1 

B2 

B3 

B4 

B5 

B6 


Figure  35.  Example  2  NODE-TBL 


To  use  tnis  Table,  a  Process  selects  a  random  fraction,  scales 
tne  fraction  to  tne  number  of  entries  in  tne  Table  by  multiplying 
and  truncates  tne  product  to  matcn  an  X-VALJE  in  tne  Table. 

Tnese  tnree  transf ormations  are  done  using  the  EVAL  Primitive. 
Since  the  message  generation  Process  can  execute  in  all  nodes,  it 
is  necessary  to  cnecx  if  the  randomly  selected  node  is  tne  source 
node.  If  so,  anotner  node  must  oe  generated.  This  tecnnigue  for 
generating  uniformly  distributed  selections  from  a  range  of 
values  is  standard  practice  in  simulation. 


The  message  generation  process,  GEW-MSG,  triggers  tne  initial 
Process  in  tne  message  routing  submodel,  REJ-I/O,  v/itn  tne 
parameters  to  generate  a  message  and  route  it  to  a  destination. 
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Figure  36.  Process  GiiiM-rtSG 

4.3.5  7er if ying  tne  Message  Routing  Submodel  and  Loop  ,4odel 

4. 3. 5.1  Single  fnread  Scenario  and  Load  A  single  tnresd 
Scenario,  fESfl,  initiates  one  instance  of  GErJ-rtSG  at  node  31. 
trace  is  generated  to  follow  tne  seguence  of  transactions  for  til 
message  to  determine  if  tne  message  is  properly  routed  to  its 
destination. 
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■SCENARIO  NAME  :  TEST1  PERIOD  LENGTH.:  50 

DESCRIP  riOW :  SINGLE  THREAD  PEST  CASE  FOR  PIERCE  LOOP 
PERIODS 
1 

TRIGGER  3CH  TIME  PRIORITY 
LOAD1  0  0 

TRACE  0  Q 


LOAD  NAME :  LOAD1 

DESCRIP now :  GENERATE  1  MESSAGE  AT  NODE  1  AFTER  1  SECOND 
NODE 

HI 

PROCESS  MAX  i  SCH  MTD  MEAN  DELTA  PRIORITY 
GEN-MSG  1  INTERVAL  1  0  U 


Figure  37.  Example  2  Single  Thread  Scenario  and  Load 


4.3.5. 2  Single  Tnread  Trace  Tne  single  tnread  crace 
execution  snows  tnt2  ss^Li^ncts  of  Proc^ss^js  on^ 

from  node  Hi  to  its  destination.  The  Process,  REC-MSG 
cated  at  the  destination.  The  trace  verifies  tnat  the 
sequence  of  Processes  occurs. 
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Figure  38.  Example  2  Single  Thread  Trace 
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4. 3.5.3  Mai  t  i  pi  e  Tar  ead  Scenar  io  and  Loads  a  reasonaole  multi¬ 
ple  tnread  Scenario  for  verifying  tne  model  initiates  six  mes¬ 
sages,  simul Cdneoasi y ,  one  at  eacn  nose  node.  As  tne  messages 
circalate  around  tne  loop,  it  is  possible  to  trace  tne  sequence 
of  events  and  detect  queueing.  me  simulation  results  produced 
snould  oe  verifiaole  by  tne  trace  output.  me  selection  of  cnis 
Scenario  is  based  on  tne  objective  of  defininq  a  small  experiment 
wniicn  can  be  nand  verified  if  necessary  in  order  to  prove  tne 
model  is  executinq  correctly. 

SCENARIO ;  TES 12  PERIOD  LENGTH:  60 
DESCRIPTION :  MULTIPLE  THREAD  SCENARIO  TEST 
PERIODS:  1 


TRIGGER 

SCH  TIME 

PRIORITY 

3TARTS1 

0 

0 

S  TARTS 2 

0 

0 

STARTS 3 

0 

0 

S  TARTS4 

0 

0 

S  TAR  TS  5 

0 

0 

STARTS6 

0 

0 

TRACE 

0 

0 

LOAD:  S TARTS 1 

DE SCR:  SINGLE  OCCURRENCE  OF  GEN-MSG  AT  SI 


N0DE1 

si 

NODE  2 

N0DE3 

N0DE4 

NODES 

N0DE6 

N0DE7 

NODES 

PROCESS 

MAX  # 

SCH  MTD 

MEAN 

DELTA  PRIORITY 

GEN— MSG 

1 

S  TART 

0 

Fiqure  39.  Example  2  Multiple  fliread  Test  Case 

Loads  STARTS2,  STARTS3,  S T ARTS 4 ,  STARTS5,  and  STARTSo  are  similar 
to  STARTS!  except  in  tne  name  in  tne  NODE1  field. 

4.3.6  Full  Loading  Scenario  Simulation  runs  of  tne  Pierce  loop 
net^orx  are  required  to  generate  response  data  for  varying  mean 
incer-ar r l val  times  of  messages  at  modes.  A  full  loading 
Scenario  specifies  for  eacn  node  a  load  wnicn  initiates  tne  gen¬ 
eration  of  messages,  distriouted  over  time  by  an  exponential  mean 
incer-arr ival  rate.  Tnis  models  Poisson  arrivals,  i.e.  random 
message  generation. 

An  example  of  a  full  loading  Scenario,  generating  messages  expon¬ 
entially  distributed  witn  a  mean  inter-arr ival  time  of  240 
seconds  at  eacn  node  is  snown  in  tne  accompanying  figure. 


SCNEARIO:  R  UN  2  4  U  PERIOD  L3NG 
DESCRIPTION :  SIX  NODE  PIERCE 
SECS. 

PERIODS:  1234 

8  9  10 

CALLS  TRIGGER  SCR  TIME 
LOADS1  0 

LOADS 2  0 

LOADB3  0 

LOADB4  0 

LOADS 5  0 

LOADB6  0 


ri:  240 

LOOP  WITii  MESSAGES  EVERY  240 


5  6  7 


PRIORI TY 
0 
0 
0 
0 
0 
0 


LOAD:  LOADS 1 

DESCR :  MESSAGES  AT  SOURCE  Si  EXPONENTIALLY  DISTRIBUTED  3Y 
C. ARRIVE 

PROCESS  MAX  t  SCH  MTD  MEAN  DELTA  PRIORITY 

GEN-MSG  100U00U0  EXPONENT  C. ARRIVE  0 


CONSTANT:  C. ARRIVE 
VALUE:  240 

DESCR:  MEAN  INTER-ARRI VAL  RATE  OF  MESSAGES  IN  SECONDS 


Figure  40.  Example  2  Full  Loading  Scenario  and  Entity 
Definitions 


Loads  LOADS2  tnrouyn  LOADS6  are  defined  similar  to  LOADSl.  The 
Constant  C. ARRIVE  is  used  to  specify  the  inter-arrival  time  in 
order  to  maxe  cnanging  tnis  value  easier. 

4.3.7  Extending  tne  Model  to  Include  Slots  and  Suffers  The 
model  descrioed  so  far  represents  tne  Pierce  loop  architecture 
and  functional  processing.  It  is  easily  built.  Using  AISIM,  tne 
Pierce  loop  model  can  be  built  and  running  witn  just  a  few  nours 
of  worn.  Tnis  is  made  possible  by  maxing  use  of  the  message 
routing  model  developed  in  Example  1,  which  performs  mucn  of  tne 
logic  for  the  loop  model,  as  yet,  tne  model  does  not  include 
one-to-one  representations  of  some  of  the  lower  level  elements  in 
tne  Pierce  loop  communication.  Tnese  include  tne  message  slots, 
node  buffers  and  slot  synchronizing  wnich  are  important  parts  of 
tnis  communication  protocol.  To  include  tnese  elements  in  tne 
model,  tne  model  built  so  far  can  be  modified. 

Tne  first  prodem  witn  modelling  slots  and  buffers  is  to  decide 
what  AISIM  entities  nave  dynamic  cnaracter istics  wnicn  map  to 
tnese  elements.  This  is  not  as  straigntforwara  as  witn  tne  loop 
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interface  units  and  cnannels  wnicn  clearly  can  oe  identified  as 
Resources . 

Slots  are  a  type  of  resource  in  tnat  a  slot  is  eitner  occupied  or 
empty.  Messages  wait  for  empty  slots.  Bat  slots  also  nave  a 
pnysical  location  in  tne  network  wnicn  changes  over  time.  Tney 
can  oe  viewed  as  transient  elements  wnicn  are  normally 
represented  in  AISIM  by  Items.  Tins  cirzeiuticn  of  slots  is  tne 
mosc  fundamental  cnarac ter  is t ic  of  this  element  so  it  is  oesc  to 
consider  slots  as  Items  and  nandle  utilisation  of  tae  slots  (nor¬ 
mally  associated  wi cn  AISIM  Resources)  witn  some  otter  mecnanism. 

faere  is  a  similar  problem  witn  modelling  buffers.  Buffers  are 
implemented  using  a  Resource  wnicn  is  storage.  Buffers  are 
ordered  nolding  areas  for  messages,  tnouyn,  so  taey  can  be  viewed 
as  aISIM  user-defined  queues.  Tne  second  view  is  tne  more 
natural  one  so  it  is  selected. 

Tae  two  decisions  for  modelling  slots  and  buffers  aave  tae  fol¬ 
lowing  implications  on  tne  model  of  tne  Pierce  loop. 

1.  Slots  circulate  around  the  loop.  Slots  contain  an  attrioute 
wnich  identifies  tne  current  node  a  slot  is  at.  Initially 
slots  must  be  given  a  current  node  and  started  circulating. 

2.  Slots  contain  messages  when  occupied. 

3.  Wnen  slots  are  empty,  a  message  can  be  removed  from  a  nost 
buffer  and  placed  in  tne  slot. 

4.  Sloes  are  received  at  nodes  and  forwarded  co  tne  next  node 
on  tne  loop. 

5.  All  messages  generated  at  a  nost  are  placed  in  tne  nost1 s 
buffer. 

From  tnis  use  of  functions  of  tne  Pierce  loop  system,  it  is  pos¬ 
sible  to  identify  four  AISIM  processes  to  define. 

STARTUP  -  Tnis  process  is  executed  once  in  every  node  at  tne 
start  of  tne  simulation.  STARTUP  models  creating  a  slot  and 
initiating  its  circulation  around  tne  areni tec ture . 

GSR-MSG  -  Tnis  Process  executes  in  every  node  and  models 
generation  of  a  message,  determining  tne  destination  node 
for  tne  message,  and  filing  tne  message  in  the  buffer  asso¬ 
ciated  witn  the  node. 

FORWARD  -  Tnis  Process  models  moving  a  slot  from  one  node  to 
tne  next  node  in  tne  loop  and  interrupting  tne  receiving 
node . 
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REC-SLOT  -  fnis  Process  models  tne  logic  of  tne  node  loop 
interface  unit  wnen  a  slot  is  received.  If  tne  slot  is 
occupied  and  tne  message  is  destined  for  tne  receiving  node, 
tne  message  is  processed.  If  tne  message  is  for  anotner 
node,  tne  slot  is  forwarded.  If  tne  slot  is  empty,  a  message 
is  placed  in  tne  slot  if  one  is  waiting  and  tne  slot  is  for¬ 
warded  . 

Tne  process  FORWARD  performs  tne  logic  done  by  tne  message  rout¬ 
ing  processes.  It  would  be  possible  to  modify  tne  message  rout¬ 
ing  processes  to  route  slots  and  this  would  be  one  approach. 
Anotner  approach  wnicn  could  be  considered  is  to  redo  tne  message 
routing  making  use  of  some  character  is  tics  of  loop  archi tectures . 
Tnis  second  approacn  is  snown  for  comparison  purposes. 

The  structure  of  tne  loop  model  using  slots  and  buffers  is  snown. 


I  SCENARIO  I 


triggers 

/ 


.» -a 

create  slot  - 
at  node  1 

given 

slot 

move 

slot 

$ 

from 

current  I 

aft 

LIU 

to  next 

LIU 

triggers 

\ 

-  select 

I  LOAD  I  source 

- node 

I 

tr iggers 

I 

-  create 

|  GEN— MSG  I  msg  at 

- node 


given  calls 
slot  I 

receive  - 

at  next  LIU  I  REC-SLOT  I 


given 

slot 


calls 


I  FORWARD  | 


Figure  41.  Example  2  Structure  Witn  SLOTS  And  SUFFERS 

4. 3. 7.1  Entity  Attributes  So  support  the  flow  of  the  processes, 
it  is  necessary  to  define  attributes  for  tne  slots  and  loop 
interface  units.  The  attributes  are  referenced  in  tne  Process. 
Eacn  slot  Item  nas  tnree  attributes  descrioed  below. 
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ITEM 


SLOT 


Item  representing  slot. 


CNODE  $CNOD£  The  node  name  wnere  eacn 


slot  is  located  at  any 

t  im.  e  . 

LENGTH 

36 

The  size  in  cnaracters 
of  eacn  slot. 

MSG 

0  or 
MSG 

If  tne  slot  is  occupied 
this  attribute  contains 
an  Item,  MSG.  If  tne 
slot  is  empty,  tnis 

attribate  is  o. 


An  alternate  mechanism  for  routing  slots  around  tne  loop  utilises 
tne  NEXT  attribute  defined  for  loop  interface  units,  nodes  Bl 
tnrougii  B6.  fnis  approacn  simplifies  tne  model  by  taking  advan¬ 
tage  of  ;ne  uni-directional  flow  of  slots.  Tiiis  approacn  means 
tnat  tne  Arcnitecture  and  Processes  can  not  be  made  independent. 
Changes  to  tne  Arcnitecture  to  model  more  or  less  nodes  on  tne 
loop  will  need  to  be  accompanied  by  tne  definition  of  loop  inter¬ 
face  unit  node  attributes.  In  the  example  below,  tne  attribute 
definitions  for  node  B1  are  snown.  BUFFER1  is  tne  dneua  associ¬ 
ated  witn  Bl  for  nolding  messages  prior  to  putting  tnem  in  slots 
on  tne  loop.  B2  in  tne  NEXT  attribute  indicates  tne  next  node  to 
forward  slots  from  Bl. 


ENTITY  ENTITY 

TTPE  NAME 

ATTR 

NAME 

AT  TR 
VALUE 

DESCRIPTION 

NODE 

RESOURCE  Bl 

Resource  for  node  repre 
senting  loop  interface 
unit  1. 

BUFFER 

BUFFER1 

T»iis  attribute  is  tne 
name  of  tne  buffer 
associated  witn  Node 

Bl. 

NEXT 

B2 

Tiiis  attribute  is  tne 
name  of  tne  next  node 
in  tne  network  to  cir¬ 
culate  the  slot  to. 

M.RO  Uf  E 

0 

Delay  time  to  route  a 

slot.  Assumed  to  oe 
zero . 


SEC/CHR  PROCRATE  Processing  rate  of  tne 

node  processor  in  sec¬ 
ond  5/  character. 

4. 3. 7. 2  Process:  START  UP  The  function  of  tne  Process  STARTUP  is 
to  create  slots  at  an  origin  node  and  initiate  tne  circulation  of 
tnem  around  a  loop.  Since  each  slot  contains  an  attribute, 

CNODE ,  wnicn  contains  tne  name  of  the  node  at  wnich  tne  slot  is 
resident,  the  attribute  is  initialized  to  tne  current  node  wicn 
tne  SCNODE  Keyword. 

The  Process  STARTUP  is  initiated  at  the  beginning  of  simulation 
and  represents  tne  system  generation  function. 


Figure  42.  Example  2  Process  STARTUP 

4. 3. 7. 3  Process:  FORWARD  Process  FORWARD  is  a  simpl if ication  of 
t»ie  logic  for  routing  over  tghe  processes  used  in  example  1. 

Tnis  Process  is  simplified  by  taxing  advantage  of  the  loop  con¬ 
straints,  which  are  that  flow  from  any  node  to  another  only  goes 
in  one  direction  to  adjacent  nodes.  Similar  logic  in  FORWARD  is 
used  as  in  CHLIO.  Tne  current  node  of  tne  SLOT  is  determined 
from  the  SLOT  attributes.  Tne  next  node  on  tne  loop  is  deter¬ 
mined  from  tne  NEXT  attribute  of  tne  current  node.  The  connect¬ 
ing  cnannel  is  determined  by  tne  SLINK  Keyword  and  tne  SLOT  is 
transmitted  across  tne  cnannel.  At  tne  next  node,  the  current 
node  attribute  of  the  SLOT  is  updated  and  tne  interrupt  Process, 
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RfiC-SLJT,  is  called 


Figure  43.  Example  2  Process  FORWARD 
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CHANNEL 


CALL 

REC-SLOT 

NO  WAIT  IS 


Figure  43.  Example  2  Process  FORWARD  (cont'd) 

4. 3. 7. 4  Process:  GEN -MSG  Process  GEN-MSG  represents  the 
activity  at  a  nost  loop  interface  unit  for  message  handling. 
Messages  are  introduced  at  tne  nost  loop  interface  unit  and  a 
destination  node  is  selected  by  random  sampling  from  tne  NDDE- 
T3L.  Tne  buffer  at  tne  nost  is  determined  and  the  message  is 
filed  onto  it  by  a  first  in-first  out  discipline.  Tne  logic  of 
this  Process  is  somewhat  more  complicated  than  in  the  instance 
tne  Process  used  in  the  high  level  structure. 


PROCESS  INITIATING  ALL  HESSACES  FROR  A  NOST  TO  ALL 


START  ]  iu 

SEN-KSG  /  NO 


fCNODE 

IS  ASSIGNED  TO 
CURRENT 


INDICATE  AND  CAVE  CNODE 


i 


INTRODUCE  NEW  HECCACE 


F-gure  44.  Exarple  2  Process  5E'h*SG 
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Figure  44.  Example  2  Process  GEN-MSG  (cont‘ d) 
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CURRENT  BUFFER 
IS  ASSIGNED  TO 
BUFFER 


INDICATE  CURRENT  BUFFER 


f  File  \ 

[use  LAST  > 

Von  buffer  use  wits  for  empty  slot 


Figure  44.  Example  2  Process  3EN-MSG  (cont'd) 

4. 3. 7. 5  Process  REC-SLOT  Process  REC-SLOT  is  tne  most  compli¬ 
cated  of  tne  loop  system  Processes  because  it  must  represent  tne 
loop  interface  unit  lo-jic  for  message  nandlinj.  fnere  are  t^o 
functions  wnicn  must  be  performed--messa^e  sending  and  message 
receiving.  fne  lo-jic  for  botii  functions  is  described  in  tne  fol 
lowing  cases. 

Case  1.  SLOT  Occupied  -  If  tne  message  is  destined  for  tne  nost 
associated  *#itn  the  current  node,  tne  message  is  removed 
from  tne  SLOT  and  processed.  The  SLOT  is  availaoie  for 
inserting  a  message  if  tne  buffer  has  one.  If  tne  mes¬ 
sage  is  not  destined  for  tne  host  of  tne  current  node, 
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the  SLOT  is  forwarded  to  tae  next  node  on  tac  loo... 

Case  2.  SLOT  Not  Occupied  -  If  the  SLOT  does  not  nave  a  message 
one  can  be  inserted  from  tne  buffer  associated  witn  tne 
current  node  loop  interface  unit.  in  eitner  case,  tne 
SLOT  is  forwarded  on  tne  loop. 


RECEIVE  HOT  SNA  PROCESS  RESSACE  ST  LIU 
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\  REC-SLOT  / 


ICNODE 
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CURRENT 
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;  iUEUE  AND  RECEIVE  MODE 


c _ /  ALLOC  \ 

'  \  / 

V  ttNODF 


.-vIftrue, 


/  SLOT  RSC 


CHECK8UF 
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:igure  45.  Example  2  Process  REC-SLOT 
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Figure  45 


Example  2  Process  REC-SLOT  (cont'd) 


4. 3. 7. 6  Scenario  and  Loads 


,o 


M 


s'% 


i.V 


LW 


J 

Zi 


r\i 


4. 3. 7. 6.1  Load :  INI  TLJAD  Load  INI TLJAD  initiates  the  Process 
STARTUP  at  all  nodes  in  the  arcnitectare  at  tne  start  of  tne 
simulation.  This  introduces  the  SLJTS  into  tiie  system  and  starts 


taem  circulating. 


LOAD:  INITLOAD 


DESCRIPTION:  S l’AR T  STLJTS  CIRCULATING  AT  ALL  NODES 


N0DE1  N0DE2  N0DE3  NODE  4 


31 


32 


33 


34 


NODES  NODES 


NODE7 


NODES 


35 


36 


PROCESS 


STARTUP 


MAX 

1 


SCH  MTD 
START 


MEAN  DELTA  PRIORI TT 


Figure  46.  Example  2  Load  INlfLOAD 


4. 3. 7. 6. 2  Load :  L0AD31  Load  L0AD31  represents  tne  initiation 
GEN-MSG  processes  at  node  31.  Instances  of  tne  process  are 
activated  exponentially  distributed  over  time  around  a  mean  time 


of 


of  275  seconds.  This  models  random  generation  of  messages. 
Similar  Loads  are  defined  for  all  tne  host  processors  on  tne 
loop. 


LOAD:  L0AD31  DESCRIPTION:  THIS  IS  THE  LOAD  TO  GENERATE  AT  31 


N0DE1  N0DE2  NODE3  N0D64 


31 

N0DE5 


NODE5  N0DE7  N0DE8 


PROCESS  MAX  k 
GEN-MSG  100 


SCH  MTD 
EXPONENT 


MEAN  DELTA  PRIORITY 


275 


0 


Figure  47.  Example  2  Load  L0AD31 


4 . 4  Analysis  of  Results 


4.4.1  Performance  Measures  The  3  nodes  in  tne  architecture 
represent  loop  interface  unit  processors.  Tne  H  nodes  represent 


r  - t  b  ~  -  —  i 

host  processors.  Tne  channels  are  modeled  by  resources  sucn  as 
3132  wnicn  represents  the  channel  between  the  loop  interface  unit 
for  nost  1  and  tne  loop  interface  unit  for  nost  2.  All  other 
Channels  are  similarly  named.  The  performance  statistics  for 
tnese  entities  are  found  in  tne  AISIM  Resource  Report. 
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4. 4. 1.2  Transmission  Time  fne  total  message  transmission  time, 
wnicn  includes  gueueing  delays  and  transmit  times,  is  found  in 
tne  Item  Report.  Tne  Item  Report  lists  the  MINIMUM,  MAXIMUM, 
MEAN  and  SfAdDARD  D£\/IAfIJd  for  tne  TIME  Id  STSfEM  for  messages. 
Tnis  is  accumulated  under  tne  Item  name  MSG.  Tne  number  of  sam¬ 
ples  in  tne  statistics  are  based  on  tne  NUMBER  DESfROTED.  Mes¬ 
sages  wnicn  nave  not  been  destroyed  at  tne  end  of  tne  simulation 
are  not  counted.  Bo tn  the  initial  model  and  tne  extended  model 
produce  tnis  statistic.  Because  tne  extended  model  wi tn  slots 
and  buffers  represented  is  at  a  more  detailed  level,  tne 
transmission  time  statistic  is  more  accurate. 


fne  loop  transmission  time,  defined  in  section  4.1.2  as  tne  time 
elapsed  from  tne  start  of  message  placement  on  tne  loop  until  tne 
last  cnaracter  is  received  and  removed  from  tne  loop,  is  not  com¬ 
puted  directly  by  tne  model,  do  structure  corresponding  to  tnis 
nas  been  built  into  tne  model.  In  order  to  get  tnis  result,  it 
is  necessary  to  eliminate  gueueing  and  processing  delays  from  tne 
total  time  in  system  for  eacn  message.  Tnis  can  be  done  by  hand 
calculation  if  this  statistic  is  reguired  altnougn  total 
transmission  time  appears  to  be  a  more  important  result. 

4.4.2  Val idating  the  Model  some  validity  for  tne  model  can  be 
ootained  oy  comparing  analytic  expected  utilisations  of  nodes  and 
cnannels  with  simulation  produced  results,  since  tne  Load  was 
defined  egually  for  all  source  nodes  of  messages,  and  destination 
nodes  were  selected  oy  a  uniform  distribution,  results  for  all 
cnannels  on  tne  loop  and  loop  interface  units  are  very  close. 
Analytically  derived  utilization  for  tne  loop  interface  units  is 
2.91*.  This  is  correlated  closely  by  the  AI3IM  MEAN  £  BUST 
statistic  for  Resources  31  tnrougn  S6  wnicn  vary  from  U.U29  to 
0.033.  Utilization  of  channels  is  computed  analytically  as 
30. 54*.  The  MEAN  i  BUST  statistic  for  Resources  B1B2,  B2B3, 

3334,  3435,  3536  and  3631  average  0.30. 

4.5  Conclusions 

file  loop  communication  system  snown  in  tnis  example  is  very 
effective  in  demonstrating  some  Key  concepts  of  AI3IM  simulation 
analysis.  Using  mucn  of  tne  logic  from  the  previous  example,  it 
was  snown  now  a  model  of  a  totally  different  system  could  be 
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constructed  very  rapidly.  f fie  niyn  level  model  could  easily  be 
Ouilt  in  one  interactive  session.  Simulation  results  for  tne 
system  could  be  obtained  within  a  matter  of  Hours.  rne  ni-jn 
level  model  represented  tne  arcnitecture,  connectivity  and  Load 
on  tne  system. 

In  order  to  jain  data  on  tne  lower  level  elements  of  the  system, 
the  lo>jic  of  the  model  was  extended  to  model  SLOTS  and  SUFFERS. 
Inis  also  could  be  accomplished  rapidly  once  tne  structure  of  tne 
model  is  laid  out. 

Techniques  used  in  this  example  for  random  sampling  from  a  number 
of  different  nodes  usinq  a  Table  and  usinq  tne  attributes  of 
Resources  and  Items  to  nold  data  on  relationships  are  applicable 
to  many  modelling  problems. 
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Bus  Communication  System  Example 


fnis  example  uses  bus  technology  as  the  common  lea t ions  medium. 

It  is  representati\/e  of  a  class  of  systems  tuat  deal  wicn  mal  ti¬ 
pi  e  nosts  communicating  over  a  necworx.  mis  example  is  intended 
to  study  tne  design  cnaracter istics  wnicn  are  oasic  to  this  type 
of  commun ica tion  system. 

5.1  Input 


5.1.1  Mission  Concept  Data  is  distributed  among  many  nosts  in  a 
networx.  Tnere  is  a  frequent  need  for  a  nost  to  access  data 
resident  in  another  nost's  files.  Rapid  communication  Detween 
hosts  is  effected  by  a  digital  communication  networx  wnicn  con¬ 
trols  communication  and  transmits  data  between  the  nosts  on 
demand.  Full  disx  tracx  transfers  are  typical  of  tne  internost 
commun ication  traffic. 

5.1.2  Problem  Perspective  a  study  of  tne  following  characteris¬ 
tics  of  bus  communications  is  basic  to  this  system: 

1.  Bus  capacity 

2.  Processor  capaoilities 

3.  Bus  Protocols 

4.  duffer  Requirements 

fne  load  on  tnis  system  can  be  viewed  as  message  traffic  wnicn  is 
tne  incidence  of  data  requests  generated  at  tne  hosts.  Random 
requests  would  represent  a  worst  case  study  for  a  specific  inter¬ 
generation  rate.  Data  request  destinations  from  each  nost  can  be 
distributed  among  tne  nosts. 

Tne  following  measures  assess  tne  performance  of  tne  communica¬ 
tion  system. 

1.  Response  fime.  Response  time  is  tne  time  from  tne  end  of 
sending  the  message  to  tne  start  of  receiving  tne  response. 
It  is  tne  user's  wait  time  after  sending  a  message  and 
before  receiving  a  reply.  Included  in  response  time  are: 

1)  the  communication  time  between  tne  end  of  tne  input  mes¬ 
sage  and  its  receipt  by  tne  destination  processor,  2)  tne 
processing  time  before  transmission  of  a  reply,  and  3)  tne 
communication  time  between  the  initiation  of  tne  reply  mes¬ 
sage  and  its  receipt  by  the  user. 

2.  Communication  Time.  Communication  time  refers  to  cne  time 
required  to  transmit  the  message  on  cne  bus.  Spec i f ical 1 y , 
it  is  tne  time  oetween  end  of  sending  tne  message  oy  tne 
originating  BIU  to  end  of  receipt  of  message  by  tne  destina¬ 
tion  processor,  plus  tne  time  between  start  of  reply  from 
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tne  processor  to  start  of  receipt  at  the  originating  BIU. 
Communication  time  is  tne  seme  as  tne  response  time  witn  tne 
processing  time  removed. 


3.  Round  Trip  Time.  Round  trip  time  measures  the  total  dura¬ 
tion  of  message  transmission  and  processing  from  start  of 
sending  tne  input  message  to  end  of  receiving  tne  reply  mes¬ 
sage.  It  is  tne  user's  total  cycle  time  from  the  time  he 
first  starts  sending  until  ne  has  received  the  entire  reply. 

5.1.3  System  Description  rne  interhost  communications  net</or< 
consists  of  two  time  division,  multiple  access  (TDM A)  buses.  A 
control  bus  contains  the  necessary  information  to  control  tne 
internost  traffic.  Data  transfers  utilize  tne  ocner  bus,  tne 
data  bus. 

Tne  basic  elements  of  tne  fDMA  bus  system  are 

1.  tne  transmission  medium,  i.e.  tne  buses; 

2.  tne  bus  interface  units  (BIUS)  wnicn  are  tne  elements  wnicn 
interface  eacn  device  with  tne  bus; 

3.  the  element  wnicn  provides  central  control  of  bus  opera¬ 
tions,  i.e.  the  networx  control  element. 

Eacn  bus  consists  of  a  serial  data  stream.  Information  is  time 
divisioned  multiplexed  onto  the  bus  by  arrant ing  it  in  intervals 
called  time  slots.  Tne  total  capacity  of  the  control  bus  is 
snared  simul taneously  by  the  hosts  and  the  networx  control  ele¬ 
ment  by  allocating  sets  of  time  slots  dynamically.  rne  time 
slots  are  sequentially  accessed.  Eacn  host  plus  tne  networx  con¬ 
trol  element  is  assigned  a  time  slot.  A  complete  cycle  of  slots 
is  called  a  frame.  A  portion  of  the  control  bus  is  allocated  to 
eacn  nost  and  tne  network  control  element  for  message  transmis¬ 
sion  . 

Tne  data  ous  is  divided  into  fixed  slots  of  512  bits.  rne  slots 
on  tne  data  bus  are  not  preallocated.  me  entire  data  bus  is 
allocated  for  a  given  transmission  between  hosts. 

Tne  message  communication  protocol  for  communications  between 
nosts  is  descrioed  by  the  following  sequence. 

1.  rfostl  places  a  "Data  Request"  message  in  a  queue  for  a  con¬ 
trol  message  output  buffer  in  the  riostl  BIU. 

2.  Wnen  a  buffer  is  available,  tne  request  message  is  queued 
for  tne  channel  and  then  transmitted  to  tne  BIU. 

3.  Tne  BIU  places  tne  request  message  in  a  preassigned  slot  on 
the  control  bus  and  tne  message  is  transmitted  to  tae  Rost2 
BIU. 
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4.  file  Host  did  queues  tne  request  message  for  transfer  to  cne 
Host2  processor. 

5.  Tne  Host2  did  sends  a  inessaqe  ac^nowl  edq.nen  t  to  tne  Hostl 
dIU  on  tne  control  bus. 

6.  Host2  processes  the  request  inessaqe  (50  ins  processinq  time)  . 

7.  Tne  Host2  readies  tne  data  message  ana  queues  it  for  tne  did 
data  output  buffers  (2). 

d .  Wnen  tne  buffers  are  available,  tne  first  portion  of  tne 
message  is  queued  and  transferred  to  tne  dIU. 

9.  Tne  did  sends  a  "dus  Request”  message  to  tne  WCS  over  tne 
control  bus  requesting  use  of  tne  data  bus. 

Id.  Tne  request  is  queued  and  processed  oy  tne  NC£,  whicn 

assigns  tne  data  input  buffers  of  tne  riostl  did  to  tne  reply 
did  rftien  tney  become  available. 

11.  Wnen  step  lu  is  completed  and  the  data  bus  becomes  avail¬ 
able,  tne  NCE  sends  a  "dus  Grant"  message  on  tne  data  bus  to 
tne  riost2  did. 

12.  dpon  receipt  of  tne  grant,  tne  riosc2  did  begins  sending  tne 
message  (44d  data  bits  per  slot)  to  the  Hostl  did  over  tne 
data  dus.  Tne  did  buffers  are  toggled  at  botn  tne  sending 
and  receiving  BIUs. 

1J.  Wnen  tne  data  message  transfer  nas  been  completed,  tne  Hostl 
did  sends  an  "AcKnowledgment"  message  to  tne  riost2  did  and  a 
"dus  Release"  message  to  tne  NCE.  do tn  messages  are  sent 
over  tne  data  bus.  fhe  Host2  tnen  releases  its  did  data 
output  buffers. 

14.  Tiie  NCE  queues  and  processes  tne  "dus  Release"  message  and 
releases  tne  data  bus  for  otner  users. 

15.  Parallel  with  step  12,  tne  Hostl  did  queues  and  transfers 
eacn  buffer  of  tne  message  to  its  host. 

16.  Wnen  tne  last  Hostl  did  input  buffer  has  oeen  transferred  to 
its  nose,  tne  did  sends  a  message  on  tne  control  bus  to  tne 
NCE  telling  it  co  release  its  data  input  buffers. 

1/.  Tne  NCE  queues  and  processes  this  message  and  releases  the 
Hostl  data  input  buffers. 
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5 . 2  P  r  el  iminar  /  Anal/sis 

5.2.1  Justi  f  y  inq  A1S1M  3  imul  a  cion  fne  cnaractur istics  of  tae 
bus  systexa  map  into  AISIi^  entities. 

1.  Procedural  Operations  -  file  sequence  for  transmitting  mes¬ 
sages  and  data  oetween  nosts  is  described  in  tae  system 
description,  fnis  is  a  structured.,  veil  defined  sequence 
wnicn  is  easily  modelled  by  procedural  loqic. 

2.  Parallel  Processinq  -  fne  nost  processors,  bus  interface 
units,  data  bus  and  network  control  element  function  in 
parallel . 

3.  Resource  Sharing  -  fne  data  ous  and  network  con  ol  element 
are  snared  between  all  nosts  tnrouqa  bus  inter'  Je  units, 
fne  snaring  of  tnese  elements  are  governed  by  ne  division, 
inultiple  access  control. 

4.  external  Loadinq  -  fne  loadinq  on  tne  network  ascribed 

by  messaqe  traffic  cnaracter i zed  by  a  messaqe  g  eration 
rate  at  eacn  nost.  Messages  are  distributed  to  all  nosts. 

5.2.2  Problem  Oef ini tion  fne  most  important  aspects  of  tne  ous 
communication  system  to  model  is  tne  interface  between  tne  nosts, 
tne  ous  interface  units,  tne  data  ous  and  tne  network  control 
element.  All  tnese  elements  in  the  system  will  be  represented, 
fne  loqic  of  each  device  is  defined  by  the  bus  protocol.  fnis 
protocol  will  be  represented  as  accurately  as  it  is  described  in 
tne  problem  statement.  fhis  includes  data  requests,  acxnowledqe 
and  control  messaqes. 

i-lodellinq  tne  arcnitecture  of  the  network  is  of  less  importance 
because  tne  network  control  element  and  data  bus  effect  direct 
connections  between  all  devices  tnrouqn  tne  bus  interface  units. 

The  pnysical  character istics  of  tne  devices  will  be  parameter ized 
by  variables.  fnis  applies  specifically  to  the  band  widtn  of  tne 
buses,  tne  processinq  rate  of  the  hosts  and  the  processinq  times 
for  messaqes  at  tne  network  control  element. 

Jueueing  and  utilization  statistics  will  be  qenerated  on  tne  host 
processors,  cnannels  between  nosts  and  interface  units,  control 
bus,  data  ous  and  tne  network  control  element. 

Simulation  runs  define  a  distribution  of  messaqes  to  be  loaded 
into  tne  system.  Messaqes  are  distriouted  by  source.  fhis  is 
described  oy  matrices  in  tne  accompanying  figure. 
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Figure  49 


Distribution  of  message  destinations  b/  source  and  4 


5.2.3  Definition  of  Objective  rne  objective  of  modelling  tne 
bus  communication  network  is  to  represent  tae  logic  of  tae  ous 
protocol  accurately  and  quantify  tae  performance  of  tae  communi¬ 
cation  oased  on  varying  load  mixes. 

3 . 3  Model  Build 

5.3.1  Design,  Plan  and  Construction  of  tae  Modej  l’ae  seven  aost 
case  will  be  represented  as  tae  system  for  tae  purposes  of  demon¬ 
strating  tais  example. 

5. 3. 1.1.  Model  Design  All  Processes  in  tae  model  represent  mes¬ 
sage  aandling  functions.  For  tais  reason,  Item  MSG  will 
represent  all  message  types.  The  first  step  in  tae  design  is  to 
determine  tae  cnaracter istic  attributes  of  tae  Item  MSG.  Tae 
actrioutes  of  MSG  will  play  a  big  part  in  tae  definition  of  tae 
model  Processes. 


Every  message  is 

Attribute 

Name 

CNODE 

DEST 

LENGTH 

ORIGIN 


described  by  tne  following  set  of  attributes: 
Attribute  Description 

Tne  current  node  in  tae  bus  network  wnicb  is 
processing  tae  message. 

Tae  destination  node  of  tae  message. 

Tbe  number  of  cnaracters  in  tae  message. 

Tae  source  node  of  tae  message  in  tne  bus  net¬ 
work. 


fyPE  Tne  type  of  tne  message,  one  of  tae  following: 

data  request,  data  message,  acknowledge  mes¬ 
sage,  bus  request,  or  bus  release. 

Tne  top  level  structure  of  tne  model  makes  up  tne  initial  model 
design.  Tae  nign  level  functions  of  tne  bus  system  are  assigned 
to  AI3IM  entities  Scenario,  Loads,  and  Processes. 
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- trol  messages. 

I 
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Creates  a  message. 
Assigns  message  attri¬ 
butes.  Transmits 
message  to  BIU. 


Receive  and  process 
messages  according  to 
type. 

\ 

\ 

-  Receive  and 

I  Processesl  process  data 
I  to  Model  |  messages, 

I  Data  Bus  |  transmit  data 
-  message 


calls 


I  processesl 
I  to  Model  | 
I  Control  | 
I  Bus  j 


Figure  5U.  Example  3  Rign  Level  Structure 

5.3. 1.2  Model  Implementation  Plan  Since  tne  Architecture  of  tne 
ous  system  is  fairly  simple,  it  is  not  a  good  idea  to  use  tne 
message  routing  suDmodei  developed  in  example  1  «mich  is  designed 
for  complicated  networxs.  i’he  dus  commun ica tion  system  is  con¬ 
siderably  different  from  tne  loop  system  described  in  example  2 
so  it  is  not  probable  tnac  any  of  tne  component  models  from  exam¬ 
ple  1  and  example  2  can  be  used  for  example.  in  this  case  it  is 
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necessary  to  build  tne  bos  system  model  from,  scratch. 

file  most  critical  element  of  tne  bas  system  is  tne  protocol 
between  tne  devices,  tne  bas  interface  units,  tne  necwor*  control 
element  and  tne  data  bus.  Priority  is  placed  on  building  tne 
Processes  modeling  tne  control  logic  of  tnese  devices  first  in 
tne  plan. 

Tne  seguence  for  constructing  tne  model  of  tne  bus  common i ca t xon 
network  is  descrioed  in  tne  following  steps. 

1.  Design  and  construct  Processes  to  model  tne  bus  interface 
uni ts . 

2.  Design  and  construct  processes  to  model  tne  network  control 
bus.  Integrate  Processes  to  tne  bus  interface  units. 

3.  Design  and  construct  Processes  to  model  tne  data  bus. 
Integrate  Process  into  tne  network  control  bus  model. 

4.  Verify  model  on  subset  of  arcni tectur e .  Define  single 
tnread  Scenario. 

5.  Build  complete  network  arcni tec ture . 

6.  Define  full  loading  and  Scenario. 

7.  Verify  complete  network  model. 

d.  Run  simulations  and  analyze  results. 

5. 3. 1.3  Process:  Bid  fne  Process  BIU  models  tne  logic  of  tne 
bus  interface  units  for  all  devices  connected  to  tne  bus.  Tne 
Process  BIU  nandles  all  message  types  and  performs  a  different 
seguence  of  logic  for  eacn  type.  mere  are  five  different  mes¬ 
sage  types  nandled  at  tne  bus  interface  unit. 

1.  Outgoing  data  reguest  messages. 

2.  Incoming  data  reguest  messages. 

3.  Bus  grant  messages. 

4.  Data  messages. 


5.  Acknowledge  messages. 


5. 3. 1.3.1  Outgoing  Data  Request  Message  Handling  For  outgoing 
data  reguest  messages,  tne  bus  interface  unit  queues  tne  message 
for  tne  network  control  bus  by  placing  tne  message  in  an  assigned 


slot  of  tne  bus.  mis  logic  can  be  represented  by  passing  tne 
message  to  tne  Process  representing  tne  control  bus  after  a  delay 
for  slot  access,  me  AI3IM  primitives  to  do  tnis  are  snown  in 


the  accompanying  figure. 
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Figure  51. 


Example  3  Bus  Interface  Unit  Logic  For  Outgoing  Data 
Request  Message 


5. 3. 1.3. 2  Incoming  Data  Request  Message  dandl ing  For  incoming 
data  request  messages,  an  acknowledge  massage  is  sent  to  tne 
requesting  nost  via  the  control  bus.  tnis  is  modelled  by  creat¬ 
ing  a  second  message,  originating  at  tne  bus  interface  unit  and 
destined  for  tne  host  requesting  data.  A  Process  SEWDACK  is 
called  wnich  will  assign  attributes  for  acknowledge  messages  and 
transmit  the  message  back  by  calling  the  Process  representing  tne 
control  bus  logic.  Tne  data  request  message  is  transmitted  from 
tne  Dus  interface  unit  to  tne  host  over  the  channel  between  these 
elements.  A  new  message  is  created  by  tne  bus  interface  unit  in 
order  to  request  the  bus.  This  message  is  placed  in  the  slot  for 
tne  control  bus.  The  AISIM  primitives  for  tnis  logic  are  snown 
in  tne  accompanying  figure. 
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Fijare  52.  example  J  Bus  Interface  Lo^ic  For  Incoming  Data 
Request  rlessa-jes  (cont'd) 


cr  ft- 


b.d.l.J.i  d  us  G  ran  c  l^lessa-j  e  Handl  i  n-j  A  message  frao1  tne  net^or* 
control  bus  to  tne  bus  interface  unit  ind i ca ti nj  a  ous  jrunt 
naoles  a  data  message  to  oe  sent  over  tne  data  bas.  f ne  atcri- 
utes  of  t ne  massage  are  assigned  to  indicate  tne  origin  and  ces- 
tination  of  tne  data  message.  It  is  reasonaole  to  determine  tne 
message  lenjtn  at  tnis  time  since  it  is  randomly  generated.  fne 
lenjtn  is  assigned  to  tne  data  message  and  it  is  passed  to  tne 
Process  representing  tne  data  bus  lo^ic. 
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Fijure  5J. 
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1  dus  Interface  Lo-jic  Por  das  Grant  ,»ies. 
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5. 3. 1.3. 4  Data  Message  Handl ing  When  a  data  message  is  received 
at  a  das  interface  unit,  an  acknowledge  message  is  created  and 
sent  via  tne  control  bus  back  to  the  host  which  sent  the  data. 
Anotner  message  is  sent  to  the  control  bus  to  indicate  tnat  the 
data  message  is  received  and  the  data  bus  can  oe  released.  Tne 
data  is  transmitted  from  tne  bus  interface  unit  to  tne  host  over 
tne  connecting  channel.  A  message  is  then  generated  to  cause  tne 
data  message  origin  nost  to  release  buffers. 
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Figure  54. 


example  3  Bus  Interface  Logic  For  Data  Message  dan¬ 
dling  (cont'd) 


5. 3. 1.4  Process :  C0NT3  J5  Tne  Process  COdfBUS  models  tine  control 
bus  logic  *nicn  is  initiated  by  a  receipt  of  a  message.  If  tne 
message  is  a  control  message  to  be  processed  by  tne  control  bus, 
tinen  tne  process  NCSPRQC  is  called  given  tne  message.  NCBPRJC 
models  tne  logic  of  tne  network  control.  If  tne  message  is  to 
anotner  device,  tnen  tne  message  is  passed  to  tne  bus  interface 
anit  nandler.  Process  BUJ,  after  setting  tne  current  node  of  tne 
message  attrioute  to  tnat  device  bus  interface  unit. 
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Figure  55.  Example  3  Control  Bus  Message  Handling  Logic 


Figure  55.  Example  3  Control  Bus  Message  Handling  Logic 
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s.i.l. 5  Process ;  NCEPROC  Tne  network  control  element  nandles 
two  types  of  messages: 


Bus  reguest  messages 


Bus  release  messages 


For  ous  reguest  messages,  buffer  space  at  tbe  destination  buffer 
interface  unit  is  reserved,  tne  data  bus  is  allocated  and  a 
buffer  grant  message  is  given  to  tne  data  bus.  rne  data  bus  and 
Duffers  remain  allocated  until  a  dus  release  is  received  at  tne 
control  ous  from  tne  receiving  bus  interface  unit.  Tnis  is 
implemented  by  tne  SUSPEND. 


For  bus  release  messages,  the  previous  instance  of  NCEPROC  for 
tne  dus  reguest  is  resumed  so  tnat  tne  bus  and  buffer  space  is 
released.  fne  message  is  then  destroyed. 
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Figure  56.  Example  3  Network  Control  Logic  (cont'd) 
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Figure  56.  Example  3  isletworx  Control  Lo-jic  (cont'd) 

5. 3. 1.6  Process :  DATABUS  The  Process  DAPABUS  represents  the 
transmission  of  data  from  one  bus  interface  unit's  output  data 
buffers  to  anotner  bus  interface  unit's  input  data  buffers.  Tne 
delay  time  for  tnis  transfer  is  computed  based  on  the  length  of 
tne  data  message  and  tne  speed  of  the  ous.  When  the  data  is 
transferred,  the  message  is  jwen  to  tne  destination  host's  bus 
interface  unit  if  tne  destination  is  a  host,  or  to  the  netrforx 
control  element. 
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Figure  57.  £xample  3  Data  Bus  Message  Handliny  Loyic 

3. 3. 1.7  Process :  3ENDACK  The  Process  SStJDACK  is  initiat 
bus  interface  unit  to  transmit  an  acxnowledyement  of  a  re 
a  data  message  from  a  receiving  interface  unit  to  tne  transmit- 
tiny  nost.  Tne  acxnowledye  messaye  is  transmitted  on  tne  data 

bus. 


Paye  117 


a  Ci, 


GIVEN 


RET'JRH 


i 


/  START  ) 

\  cendbcx  i 

'  / 


:*sc  :e:t 

I  IS  aSSISNES  TO 
HSS  2PI4IH 


au. 

so 


Figure  58.  Example  3  Acknowledge  Message  Generation 
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Figure  58.  example  i  Acknowledge  Message  Generation  (cont'd) 

5. 3. 1.8  Process :  SBNDREL  The  Process  SENDREL  is  initiated  at  a 
bus  interface  unit  to  transmit  a  ous  release  message  to  tne  net¬ 
work  control  element  so  that  tne  data  bus  can  be  freed. 
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Figure  Si>.  Example  3  Release  Data  Bus 

S.i.l.y  Process :  HOST  fhe  Process  HOST  represents  tne  process¬ 
ing  upon  receipt  at  a  Post  node  of  a  data  request  message.  me 
Host  processor  formats  a  data  message  and  sends  tne  data  to  tne 
bus  interface  unit  over  the  channel  between  the  two  devices. 

This  process  is  called  from  the  process  BXU  which  waits  after 
passing  a  data  request  message  for  the  data  to  return. 
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Figure  60.  Example  3  HOST  Data  Message  Handling 
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Figure  60.  Example  3  HOST  Data  Message  Handling  (cont'd) 
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Figure  60.  example  3  HOST  Data  Massage  Handling  (cont'd) 

5.3.1.10  Process :  ORHOST  All  activity  in  tne  bus  model  ini¬ 
tiates  witn  a  data  request  at  a  host.  Tne  process  whicn  performs 
the  logic  for  this  operation  is  called  DHHOSf.  The  Process 
ORHOSr  creates  a  data  request  message  and  is  initiated  witn  two 
parameters,  ORIGIN  wnicn  is  tne  source  of  tne  data  request,  and 
DESf  wnicn  is  the  destination  node.  The  data  request  message  is 
transmitted  across  tne  channel  between  the  host  and  the  bus 
interface  unit  and  given  to  tne  process  31 U  to  be  handled.  The 
buffar  resource  name  of  the  originating  node  host  is  embedded  in 
message  so  chat  tne  networx  control  element  can  allocate  tne 
buffers  to  receive  data  when  tne  requested  data  message  is 
received . 
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Figure  61.  Example  3  Data  Request  Message  Generation 
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Figure  61.  Example  3  Data  Request  Message  Generation  (cont'd 

5.3.2  Load  Drivers ;  processes  TOHOS T1  tnrougn  TOHOSTS  Simple 
processes  are  used  in  this  model  to  initiate  data  requests. 

Tnese  processes  are  initiated  by  the  Load,  wnich  assigns  a 
current  node  attribute  to  the  Process.  The  Process  tnen  ini¬ 
tiates  a  data  request  from  the  current  node  to  a  specific  nost  oy 
calling  tne  Process  ORHOST  providing  a  source  node  and  a  destina¬ 
tion  node.  All  Load  processes,  TOrfOSfl,  rOHJSr2,  TOHOST3, 

TOHOS T4,  TOHOST5,  and  TOHOSTS,  execute  in  nodes  Hi,  H2 ,  Hi,  34, 
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H5,  and  do .  fnis  provides  a  mecnunism  for  implementing  a  Load  on 
tne  system  described  by  a  matrix  of  iiost  nodes.  rne  Process 
diagram  for  process  fOdOSTl  is  shown  in  an  accompanying  figure. 
All  otner  Processes  are  similar  with  tne  exception  that  tne  des¬ 
tination  node  parameter  in  the  call  to  DRROST  is  different. 
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Figure  52.  Example  J  Load  Process  roHOSfl 
5 . 4  Analysis  of  Results 

5.4.1  Performance  Measure  Tne  model  as  Duild  does  not  expli¬ 
citly  produce  all  tne  performance  measures  stated  in  section 
5.1.2,  out  produces  many  statistics  from  which  to  compute  those 
measures.  Eacn  nost  is  represented  by  a  Resource  so  it  is  possi¬ 
ble  to  determine  tne  utilisation  and  queueing  for  eacn  nost  under 
tne  Resource  Report.  Response  time  is  tracked  by  tne  Item  MSG, 
so  tne  TIME  IN  SfSfEM  statistics  in  tne  Item  Report  refer  to 
this.  Tne  data  bus  and  control  bus  are  represented  on  the  system 
arcnitecture  so  they  too  are  found  in  the  Resource  Report  along 
witn  the  simulation  generated  statistics. 

5.4.2  Validation  me  easiest  method  for  validating  tne  i>us 
model  is  by  visual  analysis  of  the  Processes  compared  to  tne  step 
oy  step  description  of  tne  bus  protocol  given  in  Section  5.1.3. 
This  indicates  that  tne  sequence  of  events  represented  in  tne 
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model  matcnes  tne  sequence  of  events  indicated  in  tne  description 
of  tne  protocol. 


